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MEMORANDUM  FOR  ASSISTANT  SECRETARY  OF  DEFENSE  (COMMAND,  CONTROL, 

COMMUNICATIONS  AND  INTELLIGENCE) 

COMPTROLLER  OF  THE  DEPARTMENT  OF  DEFENSE 
ASSISTANT  SECRETARY  OF  THE  ARMY  (FINANCIAL 
MANAGEMENT) 

ASSISTANT  SECRETARY  OF  THE  NAVY  (FINANCIAL 
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ASSISTANT  SECRETARY  OF  THE  AIR  FORCE  (FINANCIAL 
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DIRECTOR,  DEFENSE  LOGISTICS  AGENCY 

SUBJECT:  Audit  Report  on  Review  of  Software  Development  at 

Central  Design  Activities  (Report  No.  92-077)  ) 


We  are  providing  this  final  audit  report  for  your 
information  and  use.  It  addresses  development  and  maintenance  of 
software  at  central  design  activities  in  DoD.  The  audit  was 
initiated  by  the  Office  of  the  Inspector  General,  DoD.  Comments 
provided  in  response  to  a  draft  of  this  report  were  considered  in 
preparing  the  final  report. 

DoD  Directive  7650.3  requires  that  all  audit  recommendations 
be  resolved  promptly.  A  "Status  of  Recommendations"  section  is 
provided  at  the  end  of  the  finding  that  identifies  the  unresolved 
recommendations  and  the  specific  requirements  to  be  addressed  in 
your  comments  on  the  final  report.  You  may  propose  alternative 
methods  for  accomplishing  desired  improvements.  Recommendations 
are  subject  to  resolution  in  accordance  with  DoD  Directive  7650.3 
in  the  event  of  nonconcurrence  or  failure  to  comment.  All 
addressees,  except  the  Army  and  the  Defense  Logistics  Agency,  are 
requested  to  provide  comments  on  the  unresolved  recommendations 
by  June  17,  1992. 

The  courtesies  extended  to  the  audit  staff  are 
appreciated.  If  you  have  any  questions  on  this  audit,  please 
contact  Mr.  Terry  L.  McKinney  at  614-1692  (DSN  224-1692)  or 
Mr.  Carl  F.  Zielke  at  693-0453  (DSN  223-0453).  We  will  give  you 
a  formal  briefing  within  15  days  of  the  date  of  this  memorandum, 
should  you  desire  it.  This  report  will  be  distributed  to  the 
activities  listed  in  Appendix  F. 


Assistant  Inspector  General 
for  Auditing 


cc : 

Secretary  of  the  Army 
Secretary  of  the  Navy 
Secretary  of  the  Air  Force 
Commandant  of  the  Marine  Corps 


Office  of  the  Inspector  General 

Audit  Report  No.  92-077  April  17,  1992 

(Project  No.  1FE-0018) 

SOFTWARE  DEVELOPMENT  AT  CENTRAL  DESIGN  ACTIVITIES 

EXECUTIVE  SUMMARY 

Introduction.  A  goal  of  the  Defense  Corporate  Information 
Management  (CIM)  initiative  is  to  place  automated  data  processing 
equipment  operations  on  a  fee-f or-service  basis.  The  Military 
Departments,  Marine  Corps,  and  Defense  Logistics  Agency  have 
central  design  activities  to  develop  and  change  their  standard 
software  systems.  DoD  Directive  7920.1,  "Life— Cycle  Management 
of  Automated  Information  Systems  (AIS),"  June  20,  1988,  requires 
the  implementation  of  DoD  Manual  7220.9-M  (the  Manual), 
"Department  of  Defense  Accounting  Manual,"  February  1988.  The 
Manual  requires  detailed  cost  accounting  for  all  assets  including 
software  development.  In  FY  1990,  the  Military  Departments, 
Marine  Corps,  and  Defense  Logistics  Agency  had  38  central  design 
activities  with  budgets  totaling  about  $1.0  billion. 

Objectives.  The  overall  objective  of  the  audit  was  to  determine 
if  the  Military  Departments,  Marine  Corps,  and  Defense  Logistics 
Agency  managed  software  changes  in  a  timely,  effective,  and 
efficient  manner  and  if  software  changes  were  planned  and  met 
users'  needs.  Specifically,  we  reviewed  the  central  design 
activities'  software  development  to  determine  whether: 

o  valid  user  requirements  existed  for  changes, 

o  economic  analyses  were  prepared  and  used  in  the  approval 
process , 

o  software  project  costs  and  elapsed  time  were  measured  and 
tracked,  and 

o  planned  objectives  and  benefits  were  achieved  for 
completed  projects. 

In  addition,  we  evaluated  internal  controls  related  to  management 
of  software  changes. 

Audit  Results.  Although  the  audit  showed  that  software  changes 
were  planned,  met  users'  needs,  and  achieved  the  planned 
objectives,  economic  analyses  were  not  prepared,  costs  were  not 
measured  and  tracked,  and  identified  benefits  were  not 
achieved.  In  addition,  the  Military  Departments  and  Defense 
Logistics  Agency  did  not  comply  with  DoD  guidance. 


Compliance  with  DoD  Cost  Accounting  Standards.  The  Military 
Departments,  Marine  Corps,  and  Defense  Logistics  Agency  did  not 
know  or  charge  the  cost  of  software  changes  in  compliance  with 
the  Manual  (Finding  A). 

Management  of  Software  Changes.  Although  software  changes 
were  planned  and  met  users'  needs,  changes  were  not  done  within 
established  deadlines.  Valid  user  requirements  existed  for  all 
software  changes,  and  planned  objectives  were  achieved;  however, 
required  cost  analyses  were  not  prepared  and  used  in  the  approval 
process  for  146  of  356  changes  reviewed,  costs  were  not  measured 
and  tracked,  elapsed  time  was  not  measured  and  tracked  for 
90  changes,  and  identified  benefits  valued  at  $18.5  million  were 
not  achieved.  Accordingly,  the  DoD  Components  could  not  measure 
how  effectively  software  changes  were  managed  (Finding  B) . 

A  matrix  of  the  audit  results  on  both  findings  is  in  Appendix  C. 

Internal  Controls.  Procedures  either  did  not  exist  or  were 
ineffective  to  reevaluate  software  changes  that  exceeded  initial 
cost  estimates  and  to  ensure  that  identified  benefits  were 
achieved  for  completed  software  changes.  These  internal  control 
weaknesses  were  not  considered  material.  A  description  of  the 
controls  assessed  is  on  page  2  in  Part  I  of  the  report. 

Potential  Benefits  of  Audit.  Because  data  were  unreliable,  this 
audit  does  not  identify  any  quantifiable  monetary  benefits. 
Implementation  of  standard  cost  accounting  will  allow  comparisons 
of  software  development  costs  at  the  38  central  design 
activities.  In  addition,  the  implementation  of  .  our 
recommendation  for  a  standard  cost  system  will  provide  a  reliable 
charge-back  mechanism  for  accomplishing  the  CIM  f ee-for-service 
initiative  (Appendix  D) . 

Summary  of  Recommendations.  We  recommended  that  a  standard  cost 
accounting  system  be  developed  and  implemented  by  the  central 
design  activities.  Also,  we  made  recommendations  relating  to 
procedures  for  preparing  and  using  economic  analyses,  recording 
labor  hours,  measuring  cost,  and  achieving  identified  benefits. 

Management  Comments.  The  Comptroller  of  the  Department  of 
Defense  did  not  provide  comments  on  our  recommendation  to  develop 
and  implement  a  single  cost  accounting  system  that  complies  with 
the  DoD  Accounting  Manual.  The  Director  for  Defense  Information 
disagreed  with  requiring  all  central  design  activities  to  use  a 
standard  project  management  system  for  recording  labor  hours. 
The  Army  and  Defense  Logistics  Agency  agreed  with  all 
recommendations.  The  Navy  and  Air  Force  agreed  with  most  of  the 
recommendations.  All  addressees,  except  the  Army  and  the  Defense 
Logistics  Agency,  should  provide  comments  on  the  final  report  by 
June  17,  1992.  Management  comments  are  discussed  in  Part  II,  and 
the  complete  texts  of  management  comments  are  in  Part  IV. 
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This  report  was  prepared  by  the  Financial  Management  Directorate, 
Office  of  the  Assistant  Inspector  General  for  Auditing,  DoD. 
Copies  of  the  report  can  be  obtained  from  the  Information 
Officer,  Audit  Planning  and  Technical  Support  Directorate 
(703)  614-6303. 


PART  I  -  INTRODUCTION 


Background 

In  November  1989,  the  Secretary  of  Defense  directed  that  a  team 
of  representatives  from  the  Military  Departments,  Defense 
Logistics  Agency  ( DLA ) ,  and  OSD  be  formed  to  study  the 
feasibility  of  consolidating  the  computer  operations  centers  and 
consolidating  the  software  design  centers  within  DoD.  The  team 
recommended  that  the  individual  data  processing  installations  and 
the  functional  software  design  centers  be  consolidated  into  DoD 
central  design  activities.  In  addition,  the  team  recommended 
that  all  data  processing  centers  and  central  design  activities 
operate  on  an  industrial  funded  (cost  recovery)  basis. 

In  January  1991,  the  Deputy  Secretary  of  Defense  approved  a  plan 
to  implement  Corporate  Information  Management  (CIM)  principles 
throughout  the  Department  of  Defense.  The  Assistant  Secretary  of 
Defense  (Command,  Control,  Communications  and  Intelligence) 
established  a  Director  for  Defense  Information  with 
responsibility  for  implementing  the  CIM  program  throughout  DoD. 
This  responsibility  included  the  development  and  implementation 
of  information  management  policies,  programs,  and  standards; 
oversight  of  all  information  management,  technology,  and  systems; 
and  the  integration  of  the  principles  of  information  management 
into  all  of  the  Department's  functional  activities. 

DoD  Directive  7920.1,  "Life-Cycle  Management  of  Automated 
Information  Systems  (AIS),"  June  20,  1988,  provides  guidance  on 
capturing  all  costs  relating  to  the  design,  development, 
deployment,  and  operation  of  automated  information  systems  that 
support  the  DoD  mission.  The  Directive  also  requires  that  the 
life-cycle  cost  be  the  actual  cost  and  that  the  actual  cost  be 
accounted  for  in  accordance  with  DoD  Manual  7220. 9-M,  "Department 
of  Defense  Accounting  Manual,"  February  1988. 

At  the  time  of  our  audit,  the  Military  Departments,  the  Marine 
Corps,  and  the  DLA  (the  entities)  had  38  central  design 
activities  and  an  annual  budget  of  about  $1.0  billion  for 
developing  and  maintaining  software  systems. 

Objectives 

The  overall  objective  of  the  audit  was  to  determine  if  the 
entities  managed  software  changes  in  a  timely,  effective,  and 
efficient  manner,  and  if  software  changes  were  planned  and  met 
user  needs.  Specifically,  we  reviewed  the  central  design 
activities'  software  development  to  determine  if: 
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o 


valid  user  requirements  existed  for  software  changes* 

o  economic  analyses  were  prepared  and  used  in  the  software 
project  approval  process, 

o  software  project  costs  and  elapsed  time  were  measured  and 
tracked,  and 

o  planned  objectives  and  benefits  were  achieved  for 
completed  projects. 

We  also  evaluated  internal  controls  relating  to  the  management  of 
software  changes. 

Scope 

We  visited  8  of  the  entities'  38  central  design  activities  (CDAs) 
(Appendix  A).  The  eight  CDAs  had  $506.6  million  of  the  total 
$953.7  million  budget  for  FY  1990.  The  audit  was  limited  to 
software  changes  completed  in  calendar  year  (CY)  1990.  .  We 
reviewed  the  policy  guidance  issued  by  the  DoD,  Military 
Departments,  Marine  Corps,  and  DLA;  the  software  planning  and 
approval  documents  for  software  changes  completed  in  CY  1990;  the 
software  change  process  including  measuring  and  tracking  costs 
and  elapsed  time;  and  procedures  and  practices  for  ensuring  that 
planned  objectives  and  benefits  were  achieved  for  completed 
projects . 

We  randomly  selected  356  of  the  4,087  software  changes  completed 
by  the  8  CDAs.  We  visited  the  CDAs  and  activities  (Appendix  E) 
responsible  for  planning,  approving,  developing,  monitoring, 
implementing,  and  following  up  on  software  changes. 

This  economy  and  efficiency  audit  was  performed  from  December 
1990  through  July  1991.  The  audit  was  made  in  accordance  with 
the  auditing  standards  issued  by  the  Comptroller  of  the  United 
States  as  implemented  by  the  Inspector  General,  DoD,  and 
accordingly  included  such  tests  of  the  internal  controls  as  were 
considered  necessary. 

Internal  Controls 


Controls  assessed.  At  the  CDAs  and  higher  level 
commands^  we  reviewed  policies  and  procedures  for  approving, 
planning,  and  monitoring  software  changes.  We  also  evaluated 
internal  controls  for  ensuring  that  changes  were  based  on  valid 
user  requirements,  required  economic  analyses  were  prepared  and 
used  in  the  approval  process,  costs  and  elapsed  time  were 
accurately  measured  and  tracked,  and  that  planned  objectives  and 
identified  benefits  were  achieved. 


2 


Internal  control  weaknesses.  The  audit  identified  no 
material  internal  control  weaknesses  as  defined  by  Public 
Law  97-255,  Office  of  Management  and  Budget  Circular  (OMB)  A-123, 
and  DoD  Directive  5010.38.  Overall,  internal  controls  were 
effective . 

Prior  Audits  and  Other  Reviews 

We  identified  eight  prior  audits  completed  from  June  1986  through 
March  1990  that  were  related  to  software  development  at  CDAs  in 
DoD.  The  audits  were  performed  by  the  audit  activities  listed  in 
Appendix  B.  The  prior  audits  showed  problems  similar  to  those 
found  in  our  audit,  even  though  the  Military  Departments,  Marine 
Corps,  and  DLA  reported  that  corrective  actions  had  been 
implemented.  We  found  the  following  specific,  recurring 

problems  s 

o  economic  analyses  were  not  performed, 
o  costs  were  not  tracked  for  software  changes, 
o  follow-up  was  not  done  on  benefits  for  completed 
projects,  and 

o  compliance  with  regulations  was  not  enforced  by 
management . 
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PART  II  -  FINDINGS  AND  RECOMMENDATIONS 


A.  COMPLIANCE  WITH  POD  COST  ACCOUNTING  STANDARDS 

The  CDAs  did  not  measure  and  track  the  cost  of  software 
development.  This  condition  occurred  because  the  Military 
Departments,  the  Marine  Corps,  and  the  DLA  (the  entities)  did  not 
require  the  CDAs  to  comply  with  DoD  Directive  7920.1,  "Life-Cycle 
Management  of  Automated  Information  Systems  (AIS),"  June  20, 
1988,  which  states  that  actual  automated  information  systems 
costs  shall  be  accounted  for  in  accordance  with  DoD  Manual 
7220. 9-M,  "Department  of  Defense  Accounting  Manual"  (Manual), 
February  1988.  As  a  result,  the  entities  did  not  know  the  cost 
of  software  changes,  and  the  planned  fee-for-service  initiative 
cannot  be  fully  implemented  by  the  Director  for  Defense 
Information. 

DISCUSSION  OF  DETAILS 


Background 


OMB  Circular  A-130,  "Management  of  Federal  Information 
Resources,"  December  12,  1985,  requires  Government  agencies  to 
account  for  all  costs  for  operating  information  technology 
facilities  and  CDAs  and  to  recover  the  costs  from  the  functional 
users.  Functional  users  include  supply,  contract  administration, 
and  payroll. 


DoD  Directive  7920.1  governs  all  DoD  programs,  projects,  and 
activities  involved  with  the  design,  development,  deployment,  and 
operation  of  automated  information  systems  that  support  DoD 
mission  areas  (including  mission-critical  applications).  DoD 
policy  is  to  control  expenditures  on  software  systems  by  ensuring 
that  the  benefits  derived  satisfy  mission  needs  to  the  greatest 
extent  possible  and  in  the  most  cost-effective  manner.  The 
Directive  tasks  the  Comptroller  of  the  Department  of  Defense  to 
ensure  implementation  by  the  Military  Departments  and  the  Defense 
agencies . 


DoD  Directive  7920.1  also  requires  that  the  head  of  each  DoD 
Component  develop  policies  and  operating  procedures  that  are 
consistent  with  provisions  of  the  Directive  and  ensure  their 
implementation  and  the  effective  application  of  automated 
information  system  life-cycle  management  principles. 


Cost  accounting  policy.  Chapter  71,  "Cost  Identification," 
of  the  Manual  states  that  the  objective  of  cost  accounting  is  to 
accumulate  and  record  all  costs  incurred  to  accomplish  a  cost 
objective,  such  as  to  carry  on  an  activity  or  operation  or  to 
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complete  a  unit  of  work  of  a  specific  job.  Chapter  75 ,  "Cost 
Distribution  for  Information  Technology  Facilities,"  provides 
accounting  requirements  and  guidance  applicable  to  cost 
distribution  for  information  technology  facilities.  Costs  that 
are  to  be  allocated  to  users  include  direct  and  indirect  charges, 
overhead,  computer  software,  space  occupancy,  supplies,  and 
contracted  services. 

Accounting  for  Software  Costs 

Life-cycle  costs.  Contrary  to  the  requirements  in  DoD 
Directive  7920.1,  none  of  the  entities  had  developed  and 
implemented  an  appropriate  cost  accounting  system  to  capture  the 
total  life-cycle  costs  incurred  for  software  development 
changes.  Operation  and  support  costs  were  not  identified  and 
allocated  for  overhead,  amortization,  and  general  and 
administrative  expenses  for  software  changes.  The  Directive 
requires  that  expenditures  on  modernization  of  existing  software 
systems  and  maintenance  be  minimized. 

Implementation  of  the  Manual.  None  of  the  CDAs  visited  had 
a  cost  accounting  system  in  compliance  with  the  Manual  for 
capturing  and  allocating  all  of  the  costs  incurred  for  software 
development  changes.  For  example,  three  of  the  CDAs  (the  Marine 
Corps  Logistics  Base,  Albany,  Georgia;  the  :y  Army  ^  Software 
Development  Center,  Fort  Lee,  Virginia;  and  ^the  Army  v.  Systems 
Information  Management  Activity,  St.  Louis,  Missouri)  ^^ther  did 
not  track  labor  hours  or  discontinued  tracking  !;;lapo r  hour S  after 
the  projects  were  2  years  old.  The  Air  Force. ,..Ijj|gist r'CS  . Command 
( AFLC )  used  an  accelerated  hourly  labor  rate^h$||tp]5lied':'  it  to 
the  actual  hours  expended  for  each  sof  twar^||^^nge  performed 
in-house.  The  Navy  Management  Systems  Office  (the 
Support  Office)  prorated  operating  budge  t'f^if^s  (excluding 
computer  operations  costs)  to  the  major  automated  information 
system  associated  with  the  software  change.  A  fee-for-service 
system  for  information  services  in  DoD  cannot  be  implemented 
until  a  standard  cost  accounting  system  is  implemented  in 
compliance  with  the  Manual. 

Action  Initiated  within  OSD 


OSD  had  initiated  action  toward  improving  cost  accounting 
operations . 

Corporate  Information  Management  (CIM).  On  October  4,  1989, 
in  response  to  the  Secretary  of  Defense  "Report  to  the  President 
on  Defense  Management,"  the  Deputy  Secretary  of  Defense  issued  a 
memorandum  to  the  DoD  Components,  creating  the  DoD  CIM.  The 
memorandum  stated  that  the  Office  of  Information  Resource 
Management,  Comptroller  of  the  Department  of  Defense,  would  be 
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responsible  for  developing  a  plan  to  integrate  information 
systems.  The  goal  was  to  reduce  the  cost  of  DoD's  management 
information  systems.  More  specifically/  Defense  Management 
Review  Directive  ( DMRD )  924,  "Consolidate  ADP  Operations  and 
Design  Centers  in  DoD,"  called  for  the  transition  of  the 
Department’s  automated  data  processing  equipment  (ADPE) 
operations  to  a  fee-for-service  operation.  On  January  14,  1991, 
DoD  issued  its  approved  "Implementation  Plan  for  Corporate 
Information  Management." 

Fee-for-service.  In  the  approved  CIM  implementation  plan, 
the  Deputy  Secretary  of  Defense  assigned  the  Assistant  Secretary 
of  Defense  (Command,  Control,  Communications  and  Intelligence) 
(ASD[C3I])  as  the  DoD  Senior  Information  Resources  Management 
Official.  Responsibilities  include: 

o  developing  and  managing  a  program  DoD-wide  for  the 
implementation,  execution,  and  oversight  of  CIM  principles; 

o  promoting  the  CIM  initiative; 

o  reviewing  and  overseeing  the  development, 
acquisition,  and  operation  of  ADPE  programs  and  information 
services; 

o  providing  assessment  of  information  .system 
life-cycle  and  functional  planning  and  performance; 

o  establishing  policies  and  programs  DoD-wide  ^r  the 
execution  of  a  fee-for-service  process;  and 

o  developing  fee-for-service  policy  and  guidance  for 
information  services  in  DoD  and  monitoring  the  DoD  transition  to 
fee-for-service. 

In  conjunction  with  the  Comptroller,  the  ASD(C3I)  was  to  develop 
a  plan  for  transitioning  to  a  fee-for-service  operation.  A 
fee-for-service  operation  charges  its  customers  the  full  cost  of 
providing  the  services.  The  Deputy  Secretary  of  Defense  set  a 
deadline  of  August  1991  for  developing  a  comprehensive 
fee-for-service  proposal.  In  a  memorandum  to  the  DoD  Components 
on  March  18,  1991,  the  Principal  Deputy  Comptroller  assigned  the 
responsibility  for  developing  the  fee-for-service  system  to  the 
Directorate  for  Automated  Data  Processing  Systems  of  the  Office 
of  the  Comptroller.  The  Principal  Deputy  Comptroller  anticipated 
that  the  DoD  would  go  to  a  fee-for-service  system  during  FY  1992 
and  required  the  involvement  of  the  DoD  Components.  We  noted 
during  visits  to  audit  sites  that  the  DoD  Components  had 
developed  plans  to  start  implementing  fee-for-service  operations 
at  selected  CDAs.  For  example,  the  Air  Force  Standard  Systems 
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Center  implemented  notional  (identifying  the  cost  of  the  service 
provided  to  the  customer)  billing  in  October  1991.  As  of  June 

1991,  the  Air  Force  Standard  Systems  Center  planned  to  implement 
a  full-cost  accounting  system  with  rate  charges  by  October  1, 

1992,  and  an  industrial  fund  operation  with  full-cost  recovery  by 
October  1,  1993. 

RECOMMENDATION  FOR  CORRECTIVE  ACTION 


We  recommend  that  the  Comptroller  of  the  Department  of  Defense 
direct  the  Military  Departments,  the  Marine  Corps,  and  the 
Defense  agencies  to  develop  and  implement  a  single  cost 
accounting  system  for  software  development  and  maintenance  that 
complies  with  DoD  Manual  7220. 9-M,  "Department  of  Defense 
Accounting  Manual,"  February  1988. 

MANAGEMENT  COMMENTS 

The  Comptroller  of  the  Department  of  Defense  did  not  provide 
comments  on  the  draft  audit  report. 

AUDIT  RESPONSE 

Comments  on  this  final  audit  report  are  required  by  May  30, 
1992.  As  required  by  DoD  Directive  7650.3,  the  comments  should 
indicate  concurrence  or  nonconcurrence  in  the  finding  and  the 
recommendation.  The  specific  requirements  for  your  comments  are 
shown  in  the  chart  below. 


STATUS  OF  RECOMMENDATION 


Respon 

se  Should 

Cover: 

Number 

Addressee 

Concur  or 
Nonconcur 

Proposed 

Action 

Completion 

Date 

A 

Comptroller,  DoD 

X 

X 

X 
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B .  MANAGEMENT  OF  SOFTWARE  CHANGES 


Our  review  of  356  software  changes  showed  that  all  were  valid 
requirements/  all  changes  were  planned  and  met  users'  needs/  and 
planned  objectives  were  achieved.  However,  150  changes  exceeded 
their  estimated  completion  dates,  required  cost  analyses  were  not 
prepared  for  146  changes,  costs  were  not  measured  and  tracked, 
elapsed  time  was  not  effectively  measured  and  tracked  for 
90  changes,  and  identified  benefits  valued  at  $18.5  million  were 
not  achieved.  The  problems  occurred  because  software  change 
procedures  either  were  not  established  or  were  not  followed.  As 
a  result,  management  could  not  measure  how  effectively  and 
efficiently  software  changes  were  managed. 

DISCUSSION  OF  DETAILS 


Background 

The  CDAs  in  DoD  were  established  to  meet  software  and  system 
design  needs  of  specific  groups  and  organizations  within  each  of 
the  Military  Departments,  the  Marine  Corps,  and  the  Defense 
agencies.  Software  changes,  which  are  requested  or  directed,  are 
made  because  of  changes  in  processing  requirements,  deficiencies 
in  software,  or  improvements  to  programs  for  greater 
efficiency.  The  five  entities  had  similar  procedures  for 
processing  software  changes.  Change  proposal  forms,  were  used  to 
request  software  changes.  The  forms  show  the  priority  of  the 
change,  the  nature  of  the  problem  or  enhancement,  a  brief 
description  of  the  benefits  to  be  achieved,  and  the  action 
taken.  Software  changes  followed  a  set  approval  process: 

o  The  requester  filled  out  and  forwarded  a  change 
request  to  the  major  command. 

o  The  major  command  either  approved  the  request 
and  forwarded  it  to  the  functional  manager  or  disapproved  the 
request  and  returned  it  to  the  requester . 

o  The  functional  manager  either  approved  or 
disapproved  the  request. 

o  If  approved,  the  request  went  to  the  software 
change  control  board  where  it  was  either  approved  or  disapproved. 

o  If  approved,  the  request  was  prioritized, 
funded,  and  sent  to  the  CDA  to  be  worked  and  implemented. 

o  After  programming  was  completed,  the  change  was 
tested  and  certified  by  the  programmer. 
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o  The  software  change  then  went  to  the  quality 
assurance  group  for  testing  and  certification. 

o  If  accepted,  the  change  was  either  tested  and 
certified  by  the  user  before  it  was  implemented  or  implemented 
without  user  testing. 

Software  Changes 

Validation  of  user  needs.  All  the  entities  had  developed 
adequate  procedures  to  ensure  that  valid  requirements  existed  for 
requested  software  changes.  Our  review  of  356  software  change 
requests  showed  that,  although  cost  analyses  were  not  performed, 
the  requests  were  supported  by  valid  needs.  The  need  for  each 
change  was  validated  in  the  approval  process.  Procedures 
required  that  all  levels  of  management  (major  command,  functional 
manager,  CDA  personnel,  and  software  change  control  board)  be 
involved  in  the  process. 

Planning  software  changes.  Software  changes  were  adequately 
planned.  The  Navy’s  Fleet  Material  Support  Office  (FMSO)  and  the 
DLA  Systems  Automation  Center  (Automation  Center)  had  formal 
detailed  plans  showing  software  projects  that  would  be  worked 
during  the  planned  cycle.  Both  activities  had  tracking  systems 
that  provided  oversight  of  the  status  of  each  change.  DLA 
required  that  the  Automation  Center  send  a  monthly  status  report 
on  each  project  to  its  headquarters,  and  the  FMSO  generated 
reports  when  requested  by  Navy  management.  The  reports  showed 
the  activities'  progress  on  each  project  and  any  anticipated 
changes  to  the  planned  estimates.  Procedures  were  established  to 
modify  plans  when  priorities  or  requirements  changed.  During  the 
audit,  the  Marine  Corps  was  in  the  process  of  developing  a  formal 
plan.  At  the  other  four  entities,  the  planning  process  was  done 
informally  by  the  functional  managers  who  determined  the  priority 
in  which  software  changes  would  be  worked. 

Planned  objectives  and  benefits.  Planned  objectives  were 
achieved^  but  seven  of  thi  eight  activities  did  not  monitor 
identified  benefits  associated  with  software  changes  to  ensure 
the  benefits  were  achieved.  There  were  43  software  changes  with 
about  $18.5  million  in  identified  benefits.  Only  the  Army's 
Systems  Integrated  Management  Activity  (the  Army's  Management 
Activity),  with  $17.1  million  of  the  $18.5  million  in  identified 
benefits,  followed  up  on  the  identified  benefits.  However,  based 
on  our  discussion  with  management  at  the  Army's  Management 
Activity,  the  identified  benefits  provided  no  real  cost  savings 
(e.g.,  cuts  in  personnel  strength,  etc.).  As  a  result,  none  of 
the  $18.5  million  in  identified  benefits  provided  any  real 
savings. 
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Except  for  the  Air  Force,  the  entities  had  not  established 
procedures  for  reevaluating  changes  that  would  exceed  initial 
estimates.  Air  Force  Regulation  700-4,  "Communications-Computer 
Systems  Program  Management  and  Acquisition  Communications 
Computer  Systems  Program  Management,"  March  15,  1985,  establishes 
that  the  requiring  command  information  system  officer  be  notified 
if  the  cost  exceeds  the  original  estimate  by  15  percent.  On  one 
project,  DLA  identified  benefits  of  $35,019;  however,  costs 
incurred  on  the  project  increased  by  $52,254 — $17,235  more  than 
the  estimated  benefits  of  the  change.  In  another  case,  a  change 
proposal  showed  an  initial  estimate  of  200  staff  hours  to 
complete  a  change  with  estimated  savings  of  more  than  $200,000. 
When  an  in-depth  estimate  of  the  change  was  made  by  the  CDA,  it 
was  determined  that  the  change  would  require  8,727  hours  to 
complete  the  project,  eliminating  the  estimated  savings. 
However,  the  change  was  approved  based  on  the  initial  estimate. 

Timeliness  of  software  changes.  We  found  that  150  software 
changes  had  not  been  completed  within  the  established  time 
frames.  Sixteen  of  those  changes  exceeded  initial  estimated 
completion  dates  by  more  than  1  year.  The  DLA  Automation  Center 
spent  $586,000  in  overtime  during  CY  1990  and  $999,000  in 
overtime  between  January  1,  1991,  and  August  31,  1991,  to  meet 
assigned  milestones.  Overtime  costs  in  CY  1990  for  the  other 
seven  CDAs  ranged  from  $15,000  to  $235,000.  For  the  50  software 
changes  reviewed  at  the  DLA  Automation  Center,  24  had  overtime 
totaling  4,060  hours.  Fourteen  of  those  24  changes  (which 
exceeded  the  estimated  completion  dates  by  as  much  as  273  days) 
used  3,411  hours  of  overtime.  Conversely,  overtime  was  also  used 
on  changes  completed  as  many  as  248  days  ahead  of  the  estimated 
completion  dates.  Overtime  should  be  used  to  meet  milestones 
that  are  cost-effective  or  hotline  or  mission  priorities. 

Preparation  and  use  of  cost  analyses.  Required  cost 
analyses  were  not  prepared  and  used  in  the  approval  process  for 
146  of  the  356  software  changes  reviewed.  DoD  Instruction 
7041.3,  "Economic  Analysis  Program  Evaluation  for  Resource 
Management,"  October  18,  1972,  requires  the  preparation  and  use 
of  cost  analyses  in  the  approval  process  for  software  change 
requests.  Furthermore,  the  Military  Departments'  regulations 
require  an  economic  analysis  if  the  estimated  cost  of  a  software 
change  exceeds  $100,000  and  a  cost  benefits  analysis  if  the 
estimated  cost  is  $100,000  or  less..  The  requirement  for  a  cost 
analysis  was  not  enforced  because  managers  either  did  not  know 
the  requirement  existed  or  they  chose  not  to  enforce  it. 
Therefore,  the  software  changes  were  approved  without  knowledge 
of  the  costs  and  benefits  associated  with  making  the  changes. 

Measurement  and  tracking  of  elapsed  time.  Elapsed  time  was 
not  tracked  for  90  software  changes.  At  the  Marine  Corps 
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Logistics  Base,  Albany/  Georgia/  only  13  of  the  26  completed 
projects  we  reviewed  had  labor  hours  charged  to  them.  At  the 
Software  Development  Center  at  Fort  Lee,  Virginia,  none  of  the 
50  completed  changes  had  elapsed  time  charged  to  them.  Except 
for  the  Software  Development  Center  at  Fort  Lee,  Virginia,  the 
CDAs  had  automated  systems  for  tracking  time  and  labor  hours. 
The  tracking  system  at  the  Air  Force  Standard  Systems  Center 
showed  the  project  control  number,  project  title,  estimated  start 
date,  scheduled  start  date,  actual  completion  date,  estimated 
hours,  and  expended  hours.  The  other  CDAs  had  similar  tracking 
systems.  Reliable  data  were  not  available  for  managing 
programmer  and  analyst  resources. 

Management  of  approved  software  changes.  All  of  the 
entities  had  project  management  systems.  However,  no  standard 
project  management  system  had  been  established  among  the 
entities.  Because  DoD  plans  to  have  a  fee-for-service  operation, 
standardization  is  needed  to  ensure  that  each  CDA  is  consistent 
in  charging  labor  hours  to  each  project.  Our  review  showed  a 
lack  of  compliance  with  instructions  and  regulations  relating  to 
the  accuracy  of  data  in  the  project  management  systems.  The 
accuracy  of  time  charged  to  projects  was  not  validated  by 
management.  Projects  were  shown  as  active  when  they  had  been 
completed  for  more  than  a  year.  One  CDA  used  two  automated 
systems,  one  for  project  management  and  the  other  for  tracking 
paperwork  on  each  software  request.  A  comparison  between  the 
systems  showed  projects  listed  on  one  system  but  not  on  the 
other.  At  another  CDA,  personnel  charged  time  to  the  wrong 
projects,  which  showed  completed  projects  with  no  time  charged  to 
them.  These  deficiencies  occurred  because  management  did  not 
provide  effective  oversight  of  the  projects. 

RECOMMENDATIONS  FOR  CORRECTIVE  ACTION 

1.  We  recommend  that  the  Director  for  Defense  Information, 
Assistant  Secretary  of  Defense  (Command,  Control,  Communications 
and  Intelligence),  require  the  Military  Departments,  Marine 
Corps,  and  the  Defense  agencies  to  use  a  standard  project 
management  system. 

2.  We  recommend  that  the  Comptrollers  of  the  Military 
Departments;  the  Fiscal  Director  of  the  Marine  Corps;  and  the 
Director,  Defense  Logistics  Agency,  establish  procedures  to 
follow  up  on  identified  economic  benefits  associated  with 
software  changes  to  ensure  that  those  benefits  are  achieved. 

3.  We  recommend  that  the  Commandant  of  the  Marine  Corps;  the 
Army  Director  of  Information  Systems  for  Command,  Control, 
Communications  and  Computers;  the  Navy  Commanding  Officer,  Naval 
Information  Systems  Management  Center;  the  Air  Force  Deputy  Chief 
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of  Staff,  Command,  Control,  Communications  and  Computers;  and  the 
Director,  Defense  Logistics  Agency: 

a.  require  that  management  prepare  and  use  cost 
analyses  in  the  approval  process  for  software  change  requests  as 
required  by  DoD  Instruction  7041.3,  "Economic  Analysis  Program 
Evaluation  for  Resource  Management,"  October  18,  1972. 

b.  verify  recorded  labor  hours,  and  use  them  in 
making  future  project  estimates. 

c.  require  that  overtime  be  used  to  meet 
milestones  that  are  cost-effective  and  to  meet  hotline  and 
mission  priority  needs. 

4.  We  recommend  that  the  Commandant  of  the  Marine  Corps;  the 
Army  Director  of  Information  Systems  for  Command,  Control, 
Communications  and  Computers;  the  Navy  Commanding  Officer,  Naval 
Information  Systems  Management  Center;  and  the  Director,  Defense 
Logistics  Agency,  develop  procedures  to  reevaluate  approved 
software  changes,  similar  to  the  Air  Force,  when  software 
development  costs  will  exceed  the  latest  estimate  by  15  percent. 

MANAGEMENT  COMMENTS 

The  Director  for  Defense  Information  disagreed  with 
Recommendation  B.I.,  stating  that  a  single  project  management 
system  is  not  needed.  As  part  of  ongoing  fee-for-service 
efforts,  the  DoD  working  group  is  developing  a  standard  set  of 
definitions  that  classify  activities  performed  within  CDAs  as 
direct,  indirect,  or  general  administrative.  These  definitions 
will  ensure  the  consistent  application  of  costs  to  all  CDA 
projects . 

The  Army  and  Defense  Logistics  Agency  agreed  with  all 
recommendations.  The  Navy  and  the  Air  Force  agreed  with  all 
recommendations  addressed  to  them  except  Recommendation  B.3.C., 
stating  that  limiting  overtime  only  to  those  milestones  that  are 
cost-effective  is  too  restrictive. 

AUDIT  RESPONSE 

We  disagree  that  a  standard  project  management  system  is  not 
needed.  The  use  of  a  single  cost  system  is  required  as 
recommended  in  Finding  A;  however,  a  standard  project  management 
system  is  also  needed  to  track  productive  and  nonproductive  hours 
and  to  show  the  labor  applied  on  each  project.  Labor  hours 
should  be  applied  to  specific  tasks,  such  as  analysis, 
flowcharting,  training,  programming,  and  documentation.  Datd  on 
those  tasks  are  needed  for  planning  future  work  loads,  staff 
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assignments  (all  employees  do  not  perform  equally  at  each  task), 
project  estimating,  performance  evaluation,  etc.  Because 
fee-for-service  is  being  implemented  DoD-wide  at  data  processing 
centers  and  automation  design  activities,  consistency  is  required 
for  comparability.  Therefore,  we  believe  Recommendation  B.l.  is 
still  valid  and  request  that  the  Director  for  Defense  Information 
reconsider  his  position  in  response  to  the  final  report. 
Regarding  Recommendation  B.3.C.,  we  changed  the  recommendation  to 
include  the  authorization  of  overtime  for  hotline  and  mission 
priorities.  Therefore,  we  request  that  the  Navy  and  the  Air 
Force  reconsider  their  positions  in  response  to  the  final  report. 


STATUS  OF  RECOMMENDATIONS 


Response  Should 

Covers 

Concur  or 

Proposed 

Completion 

Number 

Addressee 

Nonconcur 

Action 

Date 

B.l. 

B.3.c 

ASD(C3I) 

Navy  y  . 

Air  Force  - 

X 

X 

X 

X 

X 

X 

X 

X 

X 

1/  Navy  Commanding  Officer,  Naval  Information  Systems  Management  Center 

2/  Air  Force  Deputy  Chief  of  Staff,  Command,  Control,  Communications  and 
Computers . 
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PART  III  -  ADDITIONAL  INFORMATION 


APPENDIX  A 

APPENDIX  B 
APPENDIX  C 
APPENDIX  D 
APPENDIX  E 
APPENDIX  P 


-  Central  Design  Activities  in  the  Military 
Departments,  Marine  Corps,  and  the  DLA 

-  Prior  Audits 

-  Matrix  on  the  Results  of  Audit 

-  Summary  of  Potential  Benefits  Resulting  from  Audit 

-  Activities  Visited  or  Contacted 

-  Report  Distribution 
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APPENDIX  A:  CENTRAL  DESIGN  ACTIVITIES  IN  THE  MILITARY 
DEPARTMENTS,  MARINE  CORPS,  AND  THE  DLA 


Ent  i  ly 


Army 


Navy 


Mar  i  nes 


Activity _ 

Systems  integration  Management  Activity 
Army  WWMCCS  \J  information  System 
Software  Development  Center-Lee 
Software  Development  Center-Wash ington 
Software  Development  Center-Huachuca 
Software  Development  Center-Europe 
Health  Services  Command-Systems  Support 
Activity 

U.S.  Army  Engineering  Automated  Support 
Activity 
Subtotals 

Fleet  Material  Support  Office 

Navy  Management  Systems  Support  Office 
Naval  Computer  and  Telecommunications 
Command 

Navy  Comptroller  Standard  Systems 
Activity 

Navy  Regional  Data  Automation  Center 
Naval  Military  Personnel  Command 

Naval  Aviation  Depot  Operations  Center 
Education  and  Training  Program 
Management  Support  Activity 
Facilities  Systems  Office 
Naval  Weapons  Support  Center 
Navy  Regional  Data  Automation  Center 
Naval  Computer  and  Telecommunications 
Station 

Navai  Computer  and  Telecommunications 
Station 

Navy  Regional  Data  Automation  Center 
Subtotals 

Marine  Corps  Central  Design  and 
Programming  Activity 
Marine  Corps  Central  Design  and 
Programming  Activity 
Marine  Corps  Central  Design  and 
Programming  Activity 
Subtotals 


FY 


Location 

Staffing 

St.  Louis,  M0 

1,092 

Fort  Belvoir,  VA 

11 

Fort  Lee,  VA 

329 

Fairfax,  VA 

171 

Fort  Huachuca,  AZ 

112 

Zwefbrucken , 

111 

Germany 

Fort  Sam  Houston,  TX 

140 

Washington,  DC 

108 

2,074 

Meehan icsburg,  PA 

1,392 

Chesapeake,  VA 

607 

Washington,  DC 

104 

Pensacola,  FL 

213 

Washington,  DC 

136 

Washington,  DC 

160 

Patuxent  River,  MD 

45 

Pensacola,  FL 

99 

Port  Hueneme,  CA 

108 

Crane,  IN 

18 

Norfolk,  VA 

137 

Jacksonvi ! le,  FL 

88 

Pensacola,  FL 

112 

San  Francisco,  CA 

_ [9 

3,238 

Kansas  City,  MS 

308 

Albany,  GA 

296 

Quantico,  VA  215 

819 


See  footnotes  at  the  end  of  table. 


1990 _ 

Budget  ($M) 

$  59.5 
40.0 

31.3 

13.8 
8.6 
5.0 

7.4 

5.5 
$171.1 

$  81.7 

38.3 

22.1 

14.8 

13.4 

10.9 

6.7 

5.6 

5.4 

5.3 

4.5 

4.4 

3.8 

3.6 
$220.5 

$15.8 

13,0 


9.3 

$38.1 
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APPENDIX  A:  CENTRAL  DESIGN  ACTIVITIES  IN  THE  MILITARY 
DEPARTMENTS y  MARINE  CORPS,  AND  THE  DLA  (cont'd) 


FY  1990 


En 1 i ty 

Activity 

Location 

Staffing 

Budget  ($M) 

Air  Force 

Air  Force  Logistics  Command 

Wr i ght-Patterson , 

1,049 

$117.8 

AFB,  2/  OH 

Standard  Systems  Center 

Gunter  AFB,  AL 

1,483 

107.1 

Strategic  Air  Command 

Offutt  AFB,  NE 

431 

82.0 

Military  Airlift  Command 

Scott  AFB,  IL 

214 

26.9 

Electronics  Security  Command 

Kelly  AFB,  TX 

106 

26.1 

Defense  Finance  and  Accounting  Service 

Lowry  AFB,  CO 

297 

26.0 

Tactical  Air  Command 

Langley  AFB,  VA 

381 

24.8 

Command  and  Control  Systems  Office 

Tinker  AFB,  OK 

106 

18.7 

Air  Force  Military  Personnel  Center 

Randolph  AFB,  TX 

182 

9.7 

Air  Force  Systems  Command 

Andrews  AFB,  MD 

15 

5.7 

Subtota 1 s 

4,264 

$444.8 

Dl  A 

Defense  Logistics  Agency  Systems 

Automation  Center 

Columbus,  OKI 

1,157 

$  57.9 

Defense  Logistics  Service  Center 

Battle  Creek,  Ml 

290 

13.4 

Defense  Automated  Address  Systems  Office 

Dayton,  OH 

161 

7.9 

Subtotals 

1,608 

$  79.2 

Iota  1 s 

38  CDA's 

12,003 

$953.7 

FY 

1990 

En 1 i ty 

Activity  Visited 

Location 

Staffing 

Budget  ($M) 

Army 

Systems  Integration  Management  Activity 

St*  Louis,  MO 

1,092 

$  59.5 

Software  Development  Center-Lee 

Fort  Lee,  VA 

329 

31.3 

Navy 

Fleet  Material  Support  Office 

Meehan icsburg,  PA 

1,392 

81,7 

Navy  Management  Systems  Support  Office 

Chesapeake,  VA 

607 

38.3 

Mar i nes 

Marine  Corps  Central  Design  and 

Albany,  GA 

296 

13.0 

Programming  Activity 

Air  Force 

Air  Force  Logistics  Command 

Wri ght-Patterson  AFB,  OH 

1,049 

117.8 

Standard  Systems  Center 

Gunter  AFB,  AL 

1,483 

107.1 

DLA 

Defense  Logistics  Agency  Systems 

Automation  Center 

Columbus,  OH 

1  f  157 

57.9 

Total s 

8  CDA's 

7,405 

$506.6 

W  World-Wide  Military  Command  and  Control  System 
2/  Air  Force  Base 
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APPENDIX  B:  PRIOR  AODITS 


We  identified  eight  prior  audits  related  to  the  management  of 
software  development.  The  audits  were  done  by  the  General 
Accounting  Office  (GAO);  Inspector  General,  DoD;  and  the 
Military  Departments'  audit  agencies. 

General  Accounting  Office 

Audit  report.  "Software  Projects,  Army  Materiel  Command 
Spent  Millions  Without  Knowing  Total  Costs  and  Benefits,"  GAO 
Report  No.  IMTEC-86-18,  (OSD  Case  No.  6932,  June  20,  1986). 

Audit  results.  The  Logistics  Systems  Review  Committee 
( LSRC)  allowed  software  for  the  combat  service  support  system 
to  be  modified  in  violation  of  Army  regulations.  The  LSRC 
approved  system  changes  without  requiring  complete  and 
accurate  economic  analyses  and  did  not  track  project  costs. 

Recommendations .  The  report  recommended  that  the  Army 
Materiel  Command  comply  with  regulations  regarding  the 
approval  of  software  changes  and  the  tracking  and  reporting 
of  costs  associated  with  software  changes  and  review 
completed  projects  to  determine  if  benefits  and  cost 
reductions  had  been  achieved. 

Status.  Management  reported  that  corrective  actions 
were  completed  on  April  1,  1987. 

Office  of  the  Inspector  General,  DoD 

Audit  report.  "Charge-Back  Accounting  Systems  for  the 
Cost  of  Information  Technology  Resources,"  Report  No.  90-011, 
November  28,  1989. 

Audit  results.  The  charge-back  systems  for  collecting 
costs  did  not  routinely  identify  and  allocate  to  users  the 
complete  costs  of  services  provided.  This  occurred  because 
OMB  Circular  A-130  had  not  been  implemented  by  DoD  data 
processing  installations. 

Recommendations.  The  report  recommended  that  the 
Comptroller  of  the  Department  of  Defense  modify  existing 
procedures  to  fully  incorporate  the  cost  accounting, 
allocation,  and  recovery  requirements  of  OMB  Circular  A-130, 
and  that  DoD  Components'  charge-back  systems  identify, 
allocate,  and  recover  complete  costs.  In  addition,  the 
report  recommended  that  the  DoD  issue  guidance  and  standard 
procedures  for  data  processing  activities  to  follow  in 
developing  estimated  costs  when  actual  or  historical  cost 
information  is  not  readily  available. 
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APPENDIX  B:  PRIOR  AUDITS  (cont'd) 


Status.  Management  reported  that  Defense  Management  Review 
Directive  ( DMRD )  924,  dated  November  18,  1990,  directs  that 
information  services  will  be  accomplished  on  a  fee— for— service 
basis  as  soon  as  practicable. 

Audit  report.  "Management  of  the  Defense  Logistics  Agency's 
Central  Design  Activity,"  Report  No.  90-045,  March  7,  1990. 

Audit  results.  Project  development  plans  were  outdated; 
programmer  resources  were  not  allocated  according  to  priorities; 
performance  data  were  not  recorded  accurately;  oversight  reports 
were  inaccurate,  incomplete,  and  untimely;  supervisors  did  not 
ensure  that  employees  were  accurately  reporting  their  time  and 
performance;  and  overtime  was  used  to  meet  milestones  without 
regard  for  cost-effectiveness. 

Recommendations.  The  report  recommended  compliance  with 
Agency  regulations  for  planning,  allocating,  and  reporting 
resources;  requiring  accurate  reporting  of  time;  and  authorizing 
overtime  only  to  work  on  hotline  requests  and  deadlines  that  were 
cost-effective. 

Status.  Management  reported  that  corrective  actions  were 
completed  on  May  31,  1991. . 

U.S.  ARMY 

Audit  report.  "Audit  of  the  U.S.  Army  Health  Care  Systems 
Support  Activity,  Fort  Sam  Houston,  Texas,"  Army  Report  No. 
SW  88-8,  April  28,  1988. 

Audit  results.  Engineering  change  proposals  (ECPs)  were  not 
properly  prepared,  approved,  and  processed  in  a  timely  manner. 

Recommendations .  The  report  recommended  that  ECPs  be 
properly  prepared,  approved,  and  evaluated. 

Status.  Management  reported  that  corrective  actions  were 
completed  on  December  31,  1989. 

Audit  report.  "Audit  of  System  Change  Requests  U.S.  Army 
Materiel  Command  Systems  Integration  and  Management  Activity 
(Provisional),"  Army  Report  No.  MW  90-1,  October  26,  1989. 

Audit  results.  Project  management  data  were  not  recorded 
properly,  cost-benefits  analyses  were  inadequate,  and  an 
effective  system  to  validate  actual  benefits  had  not  been 
established. 
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APPENDIX  B:  PRIOR  AUDITS  (cont'd) 


Recommendations.  The  report  recommended  that  command 
establish  a  direct  labor  rate  to  accurately  allocate  operating 
costs  to  changes  and  establish  an  effective  procedure  for 
estimating  expected  benefits  and  reporting  actual  benefits. 

Status.  Management  reported  that  corrective  actions  were 
completed  on  February  8,  1991. 

U.S.  NAVY 


Audit  report.  "Development  of  the  Marine  Corps  Standard 
Supply  System  at  Marine  Corps  Logistics  Base,  Albany,  Georgia, 
Phase  I,"  Audit  No.  D40065,  October  7,  1986. 

Audit  results.  Economic  analyses  were  not  made  as  required, 
expended  hours  were  not  charged  to  the  correct  jobs,  and  planning 
and  scheduling  were  not  done. 

Recommendations .  The  report  recommended  preparing  economic 
analyses  when  significant  changes  occurred  in  development  costs, 
using  the  planning  and  scheduling  functions  of  the  Management 
Information  System  (MIS),  organizing  a  MIS  training  program,  and 
developing  a  MIS  users  manual  and  standards. 

Status.  Management  reported  that  corrective  actions  were 
completed  in  September  1986. 

Audit  report.  "Development  of  the  Marine  Corps  Standard 
Supply  System  at  Marine  Corps  Logistics  Base,  Albany,  Georgia, 
Phase  II,"  Audit  No.  D40037,  January  17,  1990. 

Audit  results.  System  development  standards  had  been 
circumvented  causing  costs  to  increase  significantly  and 
implementation  targets  to  be  delayed,  data  in  the  project  control 
system  were  incomplete  and  inaccurate,  and  required  configuration 
audits  had  not  been  done. 

Recommendations.  The  report  recommended  that  the  project 
management  and  control  system  be  used  to  provide  complete  and 
accurate  milestones,  to  develop  realistic  project  status  and 
completion  dates,  and  to  provide  accurate  project  status 
information  to  the  steering  committee. 

Status.  Management  reported  that  corrective  actions  were 
completed  in  March  1989. 

O.S.  AIR  FORCE 

Audit  report.  "Air  Force  Software  Development  Activities 
Identification  Activities  and  Cost  Tracking  and  Reporting,"  Air 
Force  Report  No.  8195414,  March  10,  1989. 
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APPENDIX  B;  PRIOR  AUDITS  ( cont ' d ) 

Audit  results.  CDAs  did  not  properly  report  software 
development  activities  in  budget  submissions,  and  program 
managers  did  not  accurately  estimate  or  track  software 
development  costs. 

Recommendations.  The  report  recommended  that  written 
guidance  be  provided  to  the  major  commands  for  budget  submissions 
and  that  the  Deputy  Chief  of  Staff,  Command,  Control, 
Communications,  and  Computers,  supplement  current  policy  with 
more  detail  to  assist  software  development  project  managers. 

Status.  Management  reported  that  corrective  actions  were 
completed  on  two  of  the  three  recommendations.  As  of 
December  11,  1991,  current  policy  had  not  been  supplemented  with 
more  detail  to  assist  software  development  project  managers. 
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APPENDIX  C:  MATRIX  ON  THE  RESULTS  OF  AUDIT 


Element  Evaluated 


Branch  of  Government 
Air  Force  Marine  Corps 


Overa I  I 


Economic  Analysis 
Prepared 

Software  Change  Planned 
1 imel i ness 
Met  Users*  Needs 
Valid  User  Requirements 
Costs  Measured 
Costs  Tracked 
Elapsed  Time  Measured 
Elapsed  Time  Tracked 
Objectives  Achieved 
Benefits  Achieved 
Internal  Controls 
I mp i emented 
Comp  I i ance  with 
Regu I  at  ions 


LEGEND: 

A  =  Adequate 
i  =  Inadequafe 
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APPENDIX  D:  SUMMARY  OF  POTENTIAL  BENEFITS  RESULTING  FROM  AODIT 


Recommendation 

Reference 


A. 


B.l. 


B.  2. 


B .  3  .  a . 


B.3.b. 


B.  3.c 


B.4. 


Description  of  Benefit 

Compliance  with  Regulations. 
Compliance  with  DoD  cost 
accounting  requirement. 
Allows  the  implementation  of 
fee-for-service  at  software 
design  activities  in  DoD. 
Improved  oversight  and 
economy. 

Economy  and  Efficiency. 
Improves  cost-effectiveness 
of  software  development. 
Allows  comparison  of  costs 
at  CDAs . 

Internal  Control. 

Ensures  that  identified 
benefits  are  achieved. 


Compliance  with  Regulations. 
Improves  cost-effectiveness 
and  management  oversight  of 
software  development. 

More  accurate  forecasting 
data.  Better  use  of  assets. 

Internal  Control. 

Improves  management  of 
software  development  and 
monitoring  of  benefits 
shown  in  the  cost  analyses. 

Internal  Control. 

Improves  management  of 
overtime  and  ensures  that  . 
overtime  is  used  on  cost- 
effective  and  mission 
priority  cases. 

Internal  Control. 

Ensures  that  identified 
benefits  are  not  exceeded 
by  increased  costs.  Also, 
determines  if  work  on  the 
software  should  be  continued 


Amount  and 
Type  of  Benefit 

Undeterminable . 

We  found  no 
reasonable  basis  to 
quantify  future 
monetary  benefits. 


Undeterminable . 

We  found  no 
reasonable  basis  to 
quantify  future 
monetary  benefits. 

Undeterminable . 

We  found  no 
reasonable  basis  to 
quantify  future 
monetary  benefits. 

Undeterminable . 

We  found  no 
reasonable  basis  to 
quantify  future 
monetary  benefits. 


Undeterminable. 

We  found  no 
reasonable  basis  to 
quantify  future 
monetary  benefits. 

Undeterminable ♦ 

We  found  no 
reasonable  basis 
to  quantify  future 
monetary  benefits. 


Undeterminable . 

We  found  no 
reasonable  basis  to 
quantify  future 
monetary  benefits. 
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APPENDIX  E:  ACTIVITIES  VISITED  OR  CONTACTED 


Office  of  the  Secretary  of  Defense 

Comptroller  of  the  Department  of  Defense,  Washington,  DC 
Director,  Defense  Information,  Assistant  Secretary  of  Defense 
(Command,  Control,  Communications  and  Intelligence), 

Washington,  DC 

Deputy  Assistant  Secretary  of  Defense  (Information  Systems), 

Assistant  Secretary  of  Defense  (Command,  Control,  Communications 
and  Intelligence),  Policies  and  Standards,  Washington,  DC 

Department  of  the  Army 

Director  of  Information  Systems  for  Command,  Control, 
Communications,  and  Computers,  Washington,  DC 
U.S.  Total  Army  Personnel  Command,  Washington,  DC 
Army  Budget  Office,  Information  Management  Division,  Washington, 

DC 

Combined  Arms  Support  Command,  Fort  Lee,  VA 
Software  Development  Center-Washington,  Falls  Church,  VA 
Software  Development  Center-Lee,  Fort  Lee,  VA 
Headquarters,  U.S.  Army  Materiel  Command,  Alexandria,  VA 
Army  Materiel  Command  Systems  Integration  and  Management 
Activity,  St  Louis,  MO 

Headquarters,  Information  Systems  Engineering  Command,  Fort 
Belvoir,  VA 

Software  Development  Center-Huachuca,  Fort  Huachuca,  AZ 
Department  of  the  Navy 

Deputy  Assistant  Secretary  of  the  Navy,  Information  Resources 
Management,  Arlington,  VA 
Naval  Air  Systems  Command,  Arlington,  VA 
Space  and  Naval  War  Systems  Command,  Arlington,  VA 

Navy  Management  Systems  Support  Office,  Chesapeake,  VA 
Naval  Sea  Systems  Command,  Arlington,  VA 
Naval  Supply  Systems  Command,  Arlington,  VA 

Fleet  Material  Support  Office,  Mechanicsburg,  PA 
Naval  Military  Personnel  Command,  Arlington,  VA 
Naval  Computer  and  Telecommunications  Command,  Washington,  DC 
Navy  Regional  Data  Automation  Center,  Washington,  DC 
Naval  Communications  Unit  Washington,  Cheltenham,  MD 
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APPENDIX  E:  ACTIVITIES  VISITED  OR  CONTACTED  (cont'd) 


Department  of  the  Air  Force 

Deputy  Chief  of  Staff,  Command,  Control,  Communications  and 
Computers,  Washington,  DC 

Deputy  Chief  of  Staff,  Logistics  and  Engineering,  Information 
Systems  Division,  Washington,  DC 
Headquarters,  Air  Force  Logistics  Command,  Office  of  the  Deputy 
Chief  of  Staff,  Communications-Computer  Systems  and  Logistics 
Management  Systems  Center,  Wright-Patterson  Air  Force  Base, 
Dayton,  OH 

Computer  Systems  Division  and  Standard  Systems  Center,  Gunter 
Air  Force  Base,  Montgomery,  AL 
San  Antonio  Air  Logistics  Center,  Directorate  of 

Communications-Computers  Systems,  Kelly  Air  Force  Base,  TX 
Air  Force  Military  Personnel  Center,  Directorate  of  Personnel 
Data  Systems,  Randolph  Air  Force  Base,  TX 
Headquarters,  Air  Force  Strategic  Command,  Deputy  Chief  of  Staff, 
Communications-Computer  Systems,  Software  Development  Division 

Marine  Corps 

Director  for  Command,  Control,  Communications,  and  Computers, 
Arlington,  VA 

Marine  Corps  Central  Design  and  Programming  Activity,  Quantico, 
VA 

Marine  Corps  Logistics  Base,  Albany,  GA 
Defense  Logistics  Agency 

Headquarters,  Defense  Logistics  Agency,  Office  of  Information 
Systems  and  Technology,  Cameron  Station,  VA 
Headquarters,  Defense  Logistics  Agency,  Comptroller,  Cameron 
Station,  VA 

Defense  Logistics  Agency  Systems  Automation  Center,  Columbus,  OH 
Defense  Logistics  Agency  Systems  Automation  Center,  Ogden,  UT 
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APPENDIX  F:  REPORT  DISTRIBUTION 


Office  of  the  Secretary  of  Defense 

Assistant  Secretary  of  Defense  (Command,  Control,  Communications 
and  Intelligence) 

Comptroller  of  the  Department  of  Defense 
Department  of  the  Army 
Secretary  of  the  Army 

Assistant  Secretary  of  the  Army  (Financial  Management) 

Department  of  the  Navy 

Secretary  of  the  Navy 
Commandant  of  the  Marine  Corps 

Assistant  Secretary  of  the  Navy  (Financial  Management) 

Department  of  the  Air  Force 
Secretary  of  the  Air  Force 

Assistant  Secretary  of  the  Air  Force  (Financial  Management  and 
Comptroller ) 

Defense  Agencies 

Director,  Defense  Logistics  Agency 
Non-DoD 


Office  of  Management  and  Budget 
U.S.  General  Accounting  Office 

NSIAD  Technical  Information  Center 

Congressional  Committees 

Senate  Subcommittee  on  Defense,  Committee  on  Appropriations 
Senate  Committee  on  Armed  Services 
Senate  Committee  on  Governmental  Affairs 

Ranking  Minority  Member,  Senate  Committee  on  Armed  Services 
House  Committee  on  Appropriations 

House  Subcommittee  on  Defense,  Committee  on  Appropriations 
Ranking  Minority  Member,  House  Committee  on  Appropriations 
House  Committee  on  Armed  Services 
House  Committee  on  Government  Operations 
House  Subcommittee  on  Legislation  and  National  Security, 
Committee  on  Government  Operations 
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PART  IV  -  MANAGEMENT  COMMENTS 


Assistant  Secretary  of  Defense  (Command,  Control,  Communications 
and  intelligence) 

Department  of  the  Army 

Department  of  the  Navy 

Department  of  the  Air  Force 

Defense  Logistics  Agency 
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MANAGEMENT  COMMENTS:  ASSISTANT  SECRETARY  OF  DEFENSE  (COMMAND, 
CONTROL,  COMMUNICATIONS,  AND  INTELLIGENCE 


OFFICE  OF  THE  ASSISTANT  SECRETARY  OF  DEFENSE 
WASHINGTON.  DC  20301  3040 

FEB  I  3  1932 


COM***«C*TIOMS 

AMO  VTOLUOCMCC 


MEMORANDUM  FOR  DIRECTOR,  FINANCIAL  MANAGEMENT  DIRECTORATE, 

OFFICE  OF  THE  INSPECTOR  GENERAL 

SUBJECT;  Draft  Audit  Report  on  Review  of  Software  Development  at 
Central  Design  Activities  (Project  No.  1FE-0018) 

This  is  in  reply  to  your  memorandum  of  December  12,  1991, 
which  forwarded  subject  report  for  review  and  comment- 

The  report  indicates  that  the  Assistant  Secretary  of  Defense 
(Command,  Control,  Communications  and  Intelligence)  (ASD(C3I>) 
and  the  Director  of  Defense  Information  (DDI )  have  lead  responsi¬ 
bility  for  implementing  fee-for-service  for  inf ormatipn  services. 
This  is  not  the  case.  Fee-for-service  is  primarily', a  financial 
management  initiative.  It  is  an  essential  part  of  the  Defense 
Business  Operations  Fund  (DBOF)  .  ■- 

As  such,  the  Directorate  for  Automated  Data  Processing 
Systems  within  the  DoD  Comptroller's  office  has  the  lead  in 
developing  a  fee-f cr-service  structure  to  manage  information 
services.  They  have  established  a  DoD-wide  working  group  to 
support  this  effort  which  includes  a  full-time  representative 
from  ASD(C3I).  In  recognition  of  this  fact,  the  proposals  to  DDI 
(referenced  on  page  13  of  the  report)  by  the  Navy  and  the  Defense 
Loqistics  Aqency  to  assume  the  lead  in  implementing  fee-for- 
service  for  Central  Design  Activities  (CDAs)  and  Data  Processing 
Installations  (DPls)  were  removed  from  the  Information  Technology 
Policy  Board's  decision  agenda. 

I  dc  not  concur  with  recommendation  B.I.,  that  the  DDI 
require  use  of  a  standard  project  management  system.  This 
recommendation  is  based  on  the  premise  that,  “standardization  is 
needed  to  ensure  that  each  CDA  is  consistent  in  charging  labor 
hours  to  each  project."  This  improvement  can  be  achieved  without 
use  of  a  standard  project  management  system.  As  part  of  ongoing 
f ee-fcr-service  efforts,  the  DoD  working  group  is  developing  a 
standard  set  of  definitions  which  classify  activities  performed 
within  CDAs  as  direct,  indirect,  or  general  and  administrative. 
These  definitions  will  ensure  the  consistent  application  of  costs 
to  projects  across  CDAs.  Also,  my  office  is  preparing  a  request 
for  technical  support  from  the  Center  for  Information  Management 
to  develop  an  automated  rate  development  package.  This  will  be 
based  on  DoD  Comptroller's  fee-for-service  guidelines,  and 
promote  standard  charging  procedures.  It  will  include: 

1.  A  standard  list  of  activities  performed  within  informa¬ 
tion  service  organizations  and  normal  classification  as 
direct,  indirect,  or  general  and  administrative. 
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MANAGEMENT  COMMENTS:  ASSISTANT  SECRETARY  OF  DEFENSE  (COMMAND, 


CONTROL,  COMMUNICATIONS,  AND  INTELLIGENCE  (cont'd) 


2.  A  rate  development  automated  model  and  users  guide 
’  outlining  the  processes  and  procedures  required  to  formu¬ 
late  hilling  rates  for  any  given  information  service 
product.  The  user's  guide  will  address  the  following 
areas: 

a.  Fnn  costing.  Identify  all  costs  incurred  by  an 
information  services  organization. 

b.  Workload.  Identify  and  define  customer,  internal, 
and  overhead  workload. 

c.  Cost  Distribution.  Identify  and  describe  all  the 
steps  required  to  allocate  indirect  costs  to  bill- 
able  products  and  services. 

d.  Percent  of  Impact  Matrix.  Identify  and  describe 
all  steps  to  allocate  direct  operating  costs  for 
computer  services  to  standard  output  measures. 

e.  Rate  Calculation  ■Process.  Identify  and  describe 
the  final  steps  required  in  developing  the  billing 
rates  for  each  product  and  services. 

Attachment  1  provides  a  copy  of  a  DDI  memorandum  on  func¬ 
tional  economic  analysis.  The  functional  economic  analysis 
follows  and  amplifies  upon  existing  DoD  economic  analysis  policy 
contained  in  DoD  Instruction  *7041.3,  "Economic  Analysis  Program 
Evaluation  for  Resource  Management,"  October  18,  1972.  This 
technique  should  be  addressed  in  the  background  section  of  Part 
I I. B.,  "Management  of  Software  Changes,"  and  referenced  in 
recommendations  B.2.,  and  B.3.a. 

The  findings  and  recommendations  in  Part  II. A.,  "Compliance 
with  DoD  Cost  Accounting  Standards,"  should  be  adjusted  to 
reflect  the  recent  decision  by  the  Financial  Management  Steering 
Committee  to  mandate  use  of  the  Automated  Payroll  Cost  and 
Personnel  System  (APCAPS)  by  all  DBOF  activities  which  do  not 
have  a  formal  cost  accounting  process.  Attachment  2  provides  a 
listing  of  activities  to  be  converted  to  APCAPS  in  FY  1992.  This 
decision  will  assist  the  Department  in  migrating  towards  a 
DoD-wide  standard  financial  system,  and  greatly  improve  cost 
accounting  operations. 

In  addition  to  the  above  concerns,  Attachment  3  recommends 
some  specific  changes  to  the  wording  in  the  report.  My  point  of 
contact  is  Mr.  Bill  Beyer,  (703)  746-7916. 


Ronald  S.  Oxley  / 
Director  ' 

Information  Services 


Attachments 


cc:  Cindy  Kendall 
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BPSICTSS  CASE  SUPPORT 


■milieu  C a»«  tealrti*  Hofei 

In  support  of  the  Director  of  Defense  Information,  the 
Institute  for  Defense  Analysis  (IDA),  has  developed  a  business 
ease  analysis  model.  It  is  imp  lamented  in  software  that  runs  on 
generally  available  personal  computers. 

Copies  of  the  software  which  implement  the  business  case 
analysis  model  and  the  associated  user  manual  can  be  obtained  by 
calling  Ms.  Cathy  Thompson,  phone  (703)  696-1280.  for 
assistance  in  using  the  modal,  call  Dr.  Tom  Frazier  at  the 
Institute  for  Defense  Analysis,  phone  (703)  845-2132. 

Personnel  preparing  or  presenting  business  cases  are 
encouraged  to  use  the  model  wherever  possible.  The  model 
supports  business  case  preparation  in  tbres  ways: 

a.  Establishes  common  definitions  sad  formats  for  describing 
cost  elements  used  in  baseline  and  alternative  analyses. 

b.  Ensures  consistent  computations  of  risk  adjusted 
discounted  cash  flow  procedure. 

e.  Establishes  s  comprehensive  presentation  format  for  tbe 
economic  analysis  conclusions  to  aid  in  preparation  and 
review. 

Business  Case  training 

A  business  case  instruction  course  is  planned  through  the 
DoD  Information  Resources  Management  College.  Arrangements  can 
be  made  through  Nr.  Prank  Hearion  at  (202)  433-3938. 

fttilnm  wcirMtee 

A  workshop  will  be  beld  July  30  through  August  1,  1991,  to 
review  component  progress  on  business  eases  to  support  FI  1992 
ADP  Development  and  Modernisation  requirements.  Mr.  Dave  lloraa, 
at  (703)  696-1280,  is  coordinating  meeting  arrangements  for  this 
ssssion  directly  with  components.  Other  workshops  may  be 
planned  to  address  specific  actions. 


Attschmsnt 


MANAGEMENT  COMMENTS:  ASSISTANT  SECRETARY  OF  DEFENSE  (COMMAND, 
CONTROL,  COMMUNICATIONS,  AND  INTELLIGENCE  (cont'd) 


The  functional  economic  analysis  follows  and  amplifies  upon 
existing  DoD  economic  analysis  policy  contained  in  DoD 
Instruction  7041.3,  and  is  developed  based  on  the  following 
principles < 

•  focus  on  business  processes  and  mission  activities. 

•  insure  identification  and  evaluation  of  business 
alternatives  prior  to  technical  considerations. 

•  tstablish  traceability  and  auditability  into  budgets  for 
mission  and  information  system  costs/benefits,  validated 
by  functional  and  financial  managers. 

•  Provide  consistency  in  the  selection,  calculation,  and 
presentation  of  cost  and  benefit  data. 

•  Adjust  cost/benefit  calculations  to  refleet  the  financial 
impact*  of  risk. 

•  Express  benefits  In  cash  terms  so  that  realisation  of 
benefits  can  be  monitored  and  audited. 

Tools,  training,  and  workshop  support  is  being  made 
available  to  assist  in  business  ease  preparation.  The 
attachment  to  this  memorandum  provides  additional  information. 


dA/VWi 

Paul  A.  Strassmann 

Director  of  Defease  Information 


attachment 
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MANAGEMENT  COMMENTS:  ASSISTANT  SECRETARY  OF  DEFENSE  ( COMMAND , 
CONTROL,  COMMUNICATIONS ,  AND  INTELLIGENCE  (cont'd) 


SmSSSSSSk 


OFFICE  OF  THE  ASSISTANT  SECRETARY  OF  OEFENSE 
WASHINGTON.  DC  *0*31-JO4O 

July  23,  1991- 


MEMORANDUM  FOB  DEPUTY  ASS  1ST  AST  SECRETARY  OF  USFKNSE 

(CIVILIAN  PERSONNEL  POLICY /EQUAL  OPPORTUNITY) 
DEPUTY  ASSISTANT  SECRETARY  OF  DEFENSE 
(HEALTH  SERVICES  OPERATIONS) 

DEPUTY  ASSISTANT  SECRETARY  OF  DEFENSE 
(LOGISTICS) 

DIRECTOR,  DEFENSE  PROCUREMENT 
DEPUTY  COMPTROLLER  (MANAGEMENT  0Y9TWS) 

DIRECTOR,  WASHINGTON  HEADQUARTERS  SERVICES 
DIRECTOR  OF  INFORMATION  SYSTEMS  FOR  C4, 

U.S.  ARMY 

CHIEF  OF  CORPORATE  INFORMATION  MANAGEMENT 
DIVISION  (US  JOINT  STAFF) 

DIRECTORS  OF  THE  DEFENSE  AGENCIES 
DIRECTOR,  DEFENSE  MEDICAL  SYSTEMS  SUPPORT  CENTER 
DEPUTY  ASSISTANT  SECRETARY  OF  THE  NAVY 
(C4X/ER/6PACE  PROGS) 

DEPUTY  ASSISTANT  SECRETARY  (COMMUNICATIONS, 
COMPUTERS  A  LOGISTICS),  U.S.  AIR  FORCE 

SUBJECT t  Corporate  information  Management  (CZM)  Business  Cat* 
(Functional  Economic  Analysis) 


Sy  supporting  functional  managers  in  streamlining  business 
methods,  DoD's  corporate  information  management  initiative  will 
aid  the  Department  in  achieving  the  aggressive  savings  targets 
established  by  the  Defense  Management  Report.  To  achieve  the 
highest  savings,  CIM  invsstments  must  bs  based  on  a  functional 
economic  analysis  of  business  activities  or  operations. 

Tba  business  case  ia  a  functional  economic  analysis  to 
support  CIM  investment  decisions.  As  CIM  investmant  programs 
proceed,  the  business  case  is  refined  end  updated.  Shis  ensures 
management  accountability  for  costs  and  banefits  and  the 
continued  viability  of  the  investment.  Technical  program  costa 
end  benefits  art  elements  of  the  total  functional  economic 
analysis. 
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MANAGEMENT  COMMENTS:  ASSISTANT  SECRETARY  OF  DEFENSE  (COMMAND, 
CONTROL,  COMMUNICATIONS,  AND  INTELLIGENCE  (cont'd) 


COMPTROLLER  OF  THE  DEPARTMENT  OF  DEFENSE 
WASHINGTON.  DC  X030M  100 


OCT  ?2  1991 


MEMORANDUM  FOR  ASSISTANT  SECRETARY  OF  THE  ARMY  (FINANCIAL 

ASSISTANT  SECRETARY  OF  THE  NAVY  (FINANCIAL 

ASSISTaSESECRETARY  OF  THE  AIR  FORCE  (FINANCIAL 
MANAGEMENT  AND  COMPTROLLER) 

DIRECTOR,  DEFENSE  FINANCE  AND  ACCOUNTING  SERVICE 

SUBJECT:  Standardisation  of  Selactod  Activities  of  the  Defense 
Business  Operation!  Fund  on  the  Automated  Payroll  Cost 
and  Personnel  System 

At  the  September  meeting  of  the  Financial  Management 
Steering  Committee,  the  use  of  the  Automated  Payroll  Coat  *n^ 
Personnel  System  (APCAPS)  wss  approved  for  all  Defense  Business 
Operations  Fund  (DBOF)  activitiea  which  do  not  have  a 
cost  accounting  proceaa.  This  decision  ancompasses  All  DBOF 
activities  that  did  not  operate  as  a  DoD  industrial  fund 
activity  prior  to  FY  1992. 

Consistent  with  the  decision  at  the  September 
the  Financial  Management  Steering  Committee,  those  activities 
listed  in  the  attachment  are  to  be  converted  to  APCAPS  in 
FY  1992.  Accordingly,  the  Defense  Finance  and  Accounting 
Service,  in  conjunction  with  the  Military  Departments, 
take  appropriate  actions  to  ensure  that  thoae  activitiea  liated 
in  the  attachment  are  converted  to  APCAPS  as  soon  as  feasible. 
The  Defense  rinance  and  Accounting  Service  is  requested  to 
submit,  by  November  22,  1991,  its  proposal  for  converting  the 
listed  DBOF  activities  to  APCAPS  in  FY  1992. 


Sean  O’Keefq 


Attachment 


Attachment  2 
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MANAGEMENT  COMMENTS:  ASSISTANT  SECRETARY  OF  DEFENSE  (COMMAND 
CONTROL ,  COMMUNICATIONS ,  AND  INTELLIGENCE  (cont'd) 
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MANAGEMENT  COMMENTS:  ASSISTANT  SECRETARY  OF  DEFENSE  (COMMAND, 
CONTROL,  COMMUNICATIONS,  AND  INTELLIGENCE  (cont'd) 


Final  Report 
Reference 


1 


2 


5 


5 


9 


9,  18 


fart  I  -  Introduction 

i  first  Daraaraph.  "The  team  recommended  that  the  indi- 
vidual'data  processing  installations  and  the  .etivi-** 

design  centers  be  consolidated  into  DoD  central  1 

tie*  "  should  read  "The  team  recommended  consolidations  ot 
individual  data  processing  installations  and  consolidations  of 
functional  software  design  centers." 

Reason:  DPI  consolidations  were  separate  from  CDA  consoli¬ 

dations  . 

Page  2,  second  paragraph.  Define  a  central  design  activity  for 
purposes  of  this  report.  What  was  the  source  used  to  identify 
the  38  CDAs  (e.g.i  budget  exhibit  43E),  and  describe  the  report- 
ing  threshold  (e.g.,  $5  million  per  year). 

Reason:  Clarify  the  scope  of  the  review. 

Page  4,  first  paragraph.  Define  "software  changes." 

Reason:  Clarify  the  scope  of  the  review. 


Fart  II  -  Findings  and  Raconaandations 

Paae  7,  first  paragraph.  Clarify  the  statement  that  "...the 
entities  did  not  require  the  CDAs  to  comply  with  DoD  Directive 
7520.1,  - " 

Reason:  It  is  not  clear  if  the  Components  failed  to  require 

compliance  in  their  implementing  instructions,  or  failed  to 
oversee  implementation. 

Paae  7,  first  paragraph.  Delete  the  last  sentence  that  "...the 
'  entities  did  not  know  the  cost  of  software  changes,  and  the 
planned  fee-for-  service  initiative  cannot  be  fully  imple¬ 
mented  by  the  Director  of  Defense  Information." 

Reason:  The  fee-f or-service  initiative  (which  is  lead  by  DoD 
Comptroller,  not  DDI )  will  establish  methodologies  to  dis¬ 
tribute  costs  to  services,  and  force  the  CDAs  to  fully 
account  for  the  cost  of  software  change. 


Page  9,  first  paragraph.  Reference  DoD  Comptroller's  unit  cost 
guidance  of  October  15,  1990. 

Reason:  This  describes  the  general  approach  that  the  DoD 
fee-for-service  working  group  is  using  to  distribute  costs  at 
CDAs. 

Page  9,  second  paragraph.  Clarify  the  statement  that  "...none  of 
the  entities  had  developed  and  implemented  an  appropriate  cost 
accounting  system  to  capture  the  total  life-cycle  costs...." 
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MANAGEMENT  COMMENTS;  DEPARTMENT  OP  THE  ARMY 


DEPARTMENT  OF  THE  ARMY 
OFFICE  OF  THE  SECRETARY  OF  THE  ARMY 
WASHIMQTOM,  OC  M1«107 


Offca  OfMtor  of  Irrfoomtton 
(Miami  tor  Command,  Control, 
Swwmmcotom,  i  Computer. 

SAIS-ADW 


18FEBC9^ 


MEMORANDUM  FOR  THE  DEPARTMENT  OF  DEFENSE,  INSPECTOR  GENERAL, 

400  ARMY  NAVY  DRIVE,  ARLINGTON,  VA 
22202-2864 

SUBJECT:  Draft  Audit  Report  on  Review  of  Software  Development 

at  Central  Design  Activities  (Project  No,  IKE-0018) 

The  following  is  provided  in  response  to  the  HQDA,  SAIG-PA 
memorandum ,  dated  17  Dec  91,  subject  as  above. 

DODIG  Recommendations  to  the  Army  Director  of  Information 
Systems  for  Command,  Control,  Communications  and  Computers 
(DISC4) : 

-  Require  the  use  of  cost  analyses  in  the  approval  process 
for  software  change  requests. 

-  Verify  recorded  labor  hours  and  use  them  to  make  future 
project  estimates. 

-  Require  that  overtime  be  used  to  meet  only  those 
milestones  that  are  cost  effective. 

-  Develop  procedures  to  reevaluate  approved  software 
changes  for  development  costs  exceeding  the  original  estimate  by 
15  percent. 

DISC4  comments:  The  following  initiatives  collectively  address 
the  above  DODIG  recommendations. 

An  OSD  led  task  force  was  established  to  facilitate 
implementation  of  automation  as  a  separate  business  area  under 
the  Defense  Business  Operations  Eund  (DBOF ) .  During  the  latter 
part  of  KY  91,  the  task  force  identified  billing  structures,  and 
cost  and  labor  accounting  systems  that  could  be  exported  to  the 
Military  Services.  These  efforts  are  a  move  toward  identifying 
and  controlling  the  total  costs  associated  with  Implementing 
software  changes. 

The  task  force  concluded  that  the  Defense  Logistics  Agency* s 
(DLA)  cost  model  for  its  central  design  activities  (CDAs)  could 
be  used  for  CDAs  across  the  DoD.  The  Army  will  submit  plans, 
including  cost  goals  for  software  design,  during  KY  92  to 
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MANAGEMENT  COMMENTS:  DEPARTMENT  OF  THE  ARMY  (COnt'd) 


££&&?  Draft  Audit  Report  on  Ivrtw of  toftjer.  De~lop«nt 
.t Central  Design  Activities  (Project  Mo.  1FE-0018) 

inplenent  ‘{Siw  «£* 

»£»  ss^ -SSM  S5 

?'  DBO*  by  Oct  92  «lth  tbe  rmlnO.r  by  RV  94. 

The  Any  also  has  an  effort,  "Information  Mission  Area 

IIMA)  Future, "  underway  which  focuses  on  identif yingan 
developing  control  functions  that  maintain  appropriate  oversight 
over  IMA  activities.  Upon  receiving  subject  IG  report,  it  has 
£en  recommended  that  the  issues  on  preparation/use  of  cost 
analyses  and  labor  hours  in  aanagingsoftwarechangerequests 
(identified  as  "configuration  control  in  DA  Pam  25  6) 
included  ajnong  IMA  Puture  initiatives.  Implementation  is 
planned  for  1st  QTR  FY  93. 

The  Any  Information  Systems  Command  has  been  developing 
and  testing  fee-for-service  for  automation  at  three  CONUS  beta 
test  sites.  This  includes  manuals  which  explain  the  procedures 
for  operating  under  fee-for-service.  The  Any  Information 
Systems  Engineering  Command  is  developing  procedures  tor  the 
Any  software  development  centers  to  manage  software  changes. 
Projected  completion  date  for  this  guidance  is  Dec  92. 

If  additional  infonation  is  required,  please  direct 
inquiries  to  Adele  McCullough-Graham,  703-614-2422. 


Colonel,  GS 
Director  for  Architecture 


CF :  SAIG-PA 

SAIS-IDT 
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MANAGEMENT  COMMENTS:  DEPARTMENT  OF  THE  NAVY 


THE  ASSISTANT  SECRETARY  OF  THE  NAVY 

(Research,  Development  and  Acquisition) 
WASHINGTON,  D  C  20350-1000 


DRAFT 


7502 

Bar:  054/92-0005 


MEMORANDUM  FOR  THE  DEPARTMENT  OF  DEFENSE  ASSISTANT  INSPECTOR 

GENERAL  FOR  AUDITING 

Subj :  DRAFT  AUDIT  REPORT  ON  REVIEW  OF  SOFTWARE  DEVELOPMENT  AT 

CENTRAL  DESIGN  ACTIVITIES  (PROJECT  NO.  1FE-0018)  - 
ACTION  MEMORANDUM 

Raf:  (a)  DODZG  Kudo  of  IS  Doc  91 

Enel:  (1)  DON  Raaponaa  to  Draft  Audit  Roport 

I  am  responding  to  your  rafaronca  (a)  raguaot  for  our 
comment  concarning  management  of  software  developaent  and 
aaintananca  at  eantral  design  activities  within  DOD. 

Wa  concur  with  Racoaaendations  B.2,  B.3.a,  B.3.b,  and  B.4; 
concur  in  part  with  Racoaaandatlon  B.3.C.  Me  have  no  ooaaant 
regarding  substance  of  Rsconaandation  A.  and  do  not  concur  with 
Recommendation  B.l.  As  outlined  in  the  anclosad  comments,  tbs 
Department  of  Navy  has  taken  or  ia  planning  specific  actions  to 
ensure  adequate  managaaent  of  software  development  and 
maintenance.  Mora  detailed  information  is  eat  forth  at  enclosure 
(1). 


As  an  administrative  aattar,  the  Marine  Corps  is  under  the 
authority  of  the  Secretary  of  the  Navy,  although  this  audit 
treats  the  Marina  Corps  as  apparently  separate  from  the 
Department  of  the  Navy  (DON) .  Within  the  DON,  the  Assistant 
Secretary  of  the  Navy  (Research,  Development  and  Acquisition)  is 
the  cognizant  authority  for  all  Information  Rasourcea  Management 
Batters.  Concerns  and  issues  with  regard  to  Marina  Corps 
activities  in  this  arena  should,  therefore,  be  directed  to  the 
ASN(RDA) . 


Copy  to: 
NAVINSGEN 
NAVCOKPT (NCB-53 ) 
CMC (FDR) 


Gerald  A.  Cann 
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MANAGEMENT  COMMENTS:  DEPARTMENT  OF  THE  NAVY  (cont'd) 


DRAFT 


D*p*rta«nt  of  th«  H.vy  Response 
to 

(  DODIC  Draft  Report  of  Doo eabor  18,  1991 
on 

Review  of  Software  Developeent 
at  Central  Design  Activities 
Project  Mo.  1PE-0018 


aacoMMKHDXTiOH  A;  standard  Cost  Accounting  System 

Hi  recommend  that  the  Comptroller  of  the  Department  of  Defense 
direct  the  Military  Departments,  Marine  Corps,  and  Defense 
agencies  to  develop  a  single  cost  accounting  system  to  comply 
with  DOD  7220. 9-M,  "Department  of  Defense  Accounting  Manual," 
February  1988 . 

DON  Poaitlon:  , 

No  comment  regarding  subit&nci  of  ricouwndfttion.  In  July  1990, 
the  Deputy  Secretary  of  Defence  approved  the  establishment  of  the 
Defense  Finance  and  Accounting  Service  (DFAS)  to  provide  for 
centralized  management  of  finance  and  accounting  function*.  They 
appear  to  be  the  appropriate  cognizant  agent,  not  the  DON. 


re commendation  b.1;  standard  Project  Management  system 

Me  recommend  that  the  Director  for  Defense  Information, 
Assistant  Secretary  of  Defense  (Command,  Control,  Communications 
and  Intelligence) ,  require  the  Military  Departments,  Marine 
Corps,  end  Defense  agencies  to  use  a  standard  project  management 

my stem. 


Do  not  concur.  The  Department  of  Defense  should  impose  only  a 
standard  methodology  and  leave  the  decision  of  which  tool  to  the 
individual  activities.  They  should  adopt  standard  metrics  and 
conventions  for  reporting  program  management.  ITPB 
Proposal  91*43,  MDXSA  as  the  Executive  Agent  for  DOD  Program 
Manager  Support  Systems, "  endeavors  to  assess  program  management 
support  tools  and  assessment  guides. 


Enclosure  ( t  j 

i  - 
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MANAGEMENT  COMMENTS;  DEPARTMENT  OF  THE  NAVY  (cont’d) 


DRAFT 


DON  COMMENTS  ON  DODIG  DRAFT  AUDIT  REPORT  °F 

SOFTWARE  DEVELOPMENT  AT  CENTRAL  DESIGN  ACTIVITIES  ,  IS  DEC  SI 


MgoMNEWDATiQN  h.2:  follow-up  of  identified  Economic  Eonofito 

V*  recommend  that  the  Comptroller's  of  the 
Departments;  ths  fiscal  Diroctor  of  the  Karine  Corps ,  *na  the 
Director,  Defense  Logistics  Agency,  establish  P^^®*^**  to 
follow  up  on  identified  economic  benefits  associated  with 
software  changes  to  ensure  that  those  benefits  ere  achieved. 

Concur ?itA»n«  component  of  Life  Cycle  Menageaent,  we  will  review 
end  validate  the  cost  savings/cost  avoidance  actually  achieved  in 
comparison  to  the  original  savings  estisates  sade  during 
functional  analysis  in  the  concept  definition/systes  development 

phase. 


perrnnfrunaTioN  B.a.et  Ose  Cost  Analysis  in  Approval  Process 

We  recommend  that  the  Commandant  of  the  Karine  Corps;  the 
Army,  Director  of  Information  Systems  for  Command,  Control, 
Communications  and  Computers;  the  Navy  Commanding  Officer,  Naval 
Information  Systems  Management  Center;  the  Air  force  Deputy  Chief 
of  Staff  Command,  Control,  Communications  and  Computers;  and  the 
Director,  Defense  Logistics  Agency  require  that  management 
prepare  and  use  cost  analyses  in  the  approval  process  for 
software  change  requests  as  require  by  DODI  7041.3,  "Economic 
Analysis  Program  Evaluation  for  Resource  Management,"  Oct  18, 
1972. 

PON  Posit  Ian;  ,  .  „  .  „  . 

concur,  projects  should  be  undertaken  only  if  shown  to  be  cost- 
beneficial,  which  has  long  been  e  standard  Department  of  the  Navy 
requirement.  However  the  cited  reference  to  DODINST  7041.3,  a 
1972  Instruction,  should  be  expanded  to  permit  the  alternative 
ose  of  criteria  specified  in  any  other  prevailing  applicable 
guidance,  such  as  Life  Cycle  Management  directive,  and  the 
emergent  use  Business  Case  Methodology  under  the  DOD  Corporate 
Information  Management  Initiative. 


Enclosure  rn 
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MANAGEMENT  COMMENTS :  DEPARTMENT  OP  THE  NAVY  (cont'd) 


DRAFT 


COM  COMMENTS  ON  DODIG  DRAFT  AUDIT  REPORT  MO.  1FE-001S  "REVIEW  OF 
SOFTWARE  DEVELOPMENT  AT  CENTRAL  DESIGN  ACTIVITIES ",  !•  DEC  91 


RKrPMMEWPATiON  B.a.b;  Uaa  Labor  Bout*  in  Project  Estimates 

Me  rtcomnd  that  th*  Commandant  of  tha  Marina  Corps;  tha 
Any,  Diractor  of  Information  System*  for  Command, Control, 
Communication!  and  Computers;  the  Navy  Commanding  Officer,  Naval 
Xnfonation  Systems  Management  Cantar;  tha  Air  Forca  Deputy  Chief 
of  staff  Coaaand,  Control,  Communications  and  Computers;  and  the 
Diractor,  Dafanaa  Logistlca  Agancy  varify  racordad  labor  hours, 
and  uaa  tha*  in  making  futura  project  aatiaataa. 

HOW  Position: 

Concur.  Th#  DON  rwcogni*#*  tb«  importance  of  accurately 
recording  labor  hour*  fron  both  an  accountability  and  legal 
viewpoint.  Tb#  DON  will  anaura  that  CDA  activities  taka 
appropriate  action  to  provida  an  accurate  audit  trail  betwaan 
their  coat  accounting  and  project  management  ayeteme,  ae  wall  as, 
anaura  the  timely  reconciliation  of  the  date  between  theee  two 
aourcee.  In  addition,  tha  DON  will  anaura  that  CDAa  utilise 
hletoricel  labor  houra  and  coata,  applicabla,  in  developing 
futura  project  eatimatea. 


■BCMPoaroATioN  B.3.C;  Liait  overtime 

Ms  recommend  that  tb#  Commandant  of  tha  Karina  Corpa;  tha 
Any,  Diractor  of  Information  Systams  for  Command,  Control, 
Communications  and  Computers;  tha  Mavy  Commanding  Offiear,  Mavai 
Information  System*  Kanagamant  Cantar;  tha  Air  Forca  Daputy  Chief 
of  staff  Command,  Control,  Communications  and  Computara;  and  tha 
Diractor,  Dafanaa  Logistics  Agancy  raquira  that  ovartima  ba  uaad 
to  mast  only  thoaa  milastonaa  that  ara  coat-af f activa . 

MW  Position; 

Concur  in  part.  Tha  limitation  of  ovartima  on  CDA  projects  to 
only  thoaa  milaatonaa  that  ara  cost  affactiva  can  not  ba  tha  sola 
govaming  factor.  Dua  data*  mandatad  by  legislation  or  higher 
authority  often  dictate  the  need/usa  of  ovartima  to  accomplish  a 
milastona.  Bovavar,  tha  DON  vill  anaura  that  CDAs  uaa  prudent 
management  in  applying  ovartima  to  meat  project  milaatonaa. 


Enclosure  { i  j 
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MANAGEMENT  COMMENTS:  DEPARTMENT  OF  THE  NAVY  (cont'd) 


DRAFT 


DON  COMMENTS  ON  DODIG  DRAFT  AUDIT  REPORT  WO.  1FK-0018  OF 

SOFTWARE  DEVELOPMENT  AT  CENTRAL  DESIGN  ACTIVITIES",  18  DEC  81 


■g«»omrc>>TioK  B .  4 :  Reevaluate  Approved  Software  Efforts  Khan 

Coot  Orowth  Exceeds  ISt 

M  recommend  that  tha  Commandant  of  tha  Karina  Corps;  the 
Any,  Diractor  of  Information  Syatama  for  Command,  Control, 
Communications  and  Computara;  tha  Navy  Commanding  Offiear,  Naval 
Information  Syatama  Managamant  Cantar;  and  tha  Diractor,  Defense 
Logistics  Agancy  davalop  procaduras  to  raevaluata  approved 
•oft vara  ehangas,  similar  to  tha  Air  Force ,  when  software 
tfavalopmant  coats  will  exceed  tha  latest  estimate  by  15  percent. 

PPN  Ppiltlan;  M  _  .  .  . 

Concur.  Certainly  software  development  efforts  which  exceed 
Initial  estimates  need  to  be  communicated.  Tha  Department  of 
Defense  standard  project  management  methodology  would  address 
•oftwara  development  costs.  ITPB  Proposal  91-43  ,  "DISA  as  the 
Executive  Agent  for  DOD  Program  Manager  Support  Systems," 
endeavors  to  assess  program  management  support  tools  and 
assessment  guides. 


Enoosure  \T) 
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M ftMAG EMENT  COMMENTS:  DEPARTMENT  OF  THE  AIR  FORCE 


Final  Report 
Reference 


13 


otPAimsENT  ©f  tms  air  pomc* 

kwitm  uwrrtp  rrm*  react 


iini«2 


MEMORANDUM  FOR  ASSISTANT  XMSFECTOR  OCNERA1FOR  AUDITING 

office  or  the  inspector  general 

DEPARTMENT  OF  DEFENSE 


WDJECTj  DeS(IC)  Draft  Report,  •Review  of  loftwora  Dovolopoant 
•t  Central  Design  Activities  {Frojeet  No.  1FI-0018)  - 
two  wan  on  memorandum 

Tfel*  la  in  reply  to  your  memorandum  for  Assistant  Secretary 
of  the  Air  reree  (Financial  Management}  requesting-ornaments  on 
finding*  and  recommendation*  made  in  the  subject  report. 


•*  eoneur  eith  the  recommendation  for  corrective  action  on 
page  13  ef  the  draft  report.  Me  alee  eoneur  with  recommendation* 
1,  2,  3a,  30,  and  4  on  page*  22  and  23  of  tha  draft  report. 

Me  nonconcur  with  recommendation  3c  on  page  23  of  the  draft 
report.  Thi*  recommendation  *ugge*t*  that  appropriate  office*  in 
the  service*  and  Agancie*  "... require  that  overtime  be  used  to 
meet  only  tho*e  milestone*  that  are  coat-effective .  *  Coat  i*  not 
the  only  basi*  for  determining  need  date*  for  software  written 
within  the  Department  of  Defense.  Operational  mi**ion 
requirement  date*  may  at  time*  validly  require  a  more  costly 
approach  to  problem  solution.  Me  propose  the  recommendation  be 
reworded  to  "...require  that  overtime  be  used  to  meet  only  those 
milestones  that  are  cost-effective  or  which  are  driven  by 
operational  mission  needs." 

Me  also  recommend  e  clarification  in  the  background  section 
of  the  draft  report.  The  first  paragraph  on  page  1  describe*  the 
background  of  Defense  Management  Report  Directive  (DMRD)  S24  as 
of  November  1389,  but  doe*  not  relay  the  feet  that  the  final 
DMRD,  signed  by  DEPSECDEF  on  II  November  1990,  was  different. 
Recommend  adding  the  following  to  the  end  of  the  first  paragraph, 
page  1,  of  the  draft  report:  "The  Services  and  Defense  Ageneies 
war#  also  asked  to  submit  alternate  proposals.  The  final  .Defense 
Management  Report  Directive  924  of  18  November  1990  directed  that 
the  individual  Service  and  Defense  Logistics  Agency  AD? 
consolidation  plans  etrve  as  the  basis  for  consolidating  computer 
operations  and  design  canters  within  OSD.  ree-fer-eerviee 
operations  were  still  directed." 
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MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY 


MHO 


DLA-CI 


DEFENSE  LOGISTICS  AGENCY 
HEADQUARTERS 
CAMERON  STATION 
ALEXANDRIA,  VIRGINIA  22SO4-S100 


MEMORANDUM  FOR  ASSISTANT  INSPECTOR  GENERAL  FOR  AUDITING , 
DEPARTMENT  OF  DEFENSE 


SUBJECT:  Draft  Audit  Report  on  the  Review  of  Software 

Development  at  Central  Design  Activities  (Project  No« 
1FE-0018) 


This  is  in  response  to  your  IB  December  2001  memorandum 
requesting  our  comments  pertaining  to  the  subject  audit.  The 
attached  positions  have  been  approved  by  Ms.  Helen  T.  McCoy, 
Deputy  Comptroller,  Defense  Logistics  Agency. 


0  Enel 


Office  of  Comptroller 
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MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


FORMAT  1  of  0  DATE  OF  POSITION:  C  Mar  02 

TYPE  OF  REPORT;  AUDIT 

PURPOSE  OF  INPUT;  INITIAL  POSITION 

AUDIT  TITLE  AND  NO.:  REVIEW  OF  SOFTWARE  DEVELOPMENT  AT  CENTRAL 

DESIGN  ACTIVITIES,  (Project  No.  1FE-001B) 

FINDING  A:  Compliance  with  DoD  Cost  Accounting  Standards .  The 
CDAs  did  not  measure  and  track  the  coat  of  software  development. 

DLA  COMMENTS:  Concur.  DLA  has  not  followed  DoD  7220. B“M  in  it# 
entirety.  The  new  DLA  ADP/T  Configuration  Management  process 
include®  coet  accounting  for  software  development  and 
maintenance.  The  methodology  utilised  for  coat  accounting  shall 
be  in  accordance  with  DoD  7220. fi-M  as  applicable. 

INTERNAL  MANAGEMENT  CONTROL  WEAKNESS; 

(  )  Nonconcur  (Rationale  must  be  documented  and  maintained 
with  your  copy  of  the  response.) 

(X)  Concur;  however,  weakness  is  not  considered  material. 

(Rationale  must  be  documented  and  maintained  with  your  copy 
of  the  response . ) 

t  )  Concur;  weakness  is  material  and  will  be  reported  in  the 
DLA  Annual  Statement  of  Assurance. 

ACTION  OFFICER:  Donna  McCloud,  DLA-ZSS ,  x44326.  27  Jan  02 

PSE  REVIEW/ APPROVAL :  Bobby  L.  Parsons ,  DLA-ZD ,  Deputy  Assistant 

Director,  Office  of  Information  Systems 
and  Technology,  X46257,  31  Jan  02 

DLA  APPROVAL;  Belen  T.  McCoy ,  Deputy  Comptroller 


i 
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MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


„  „  „  BATE  or  POSITION:  9  Iter  S3 

FORMAT  2  Of  B 

TYPE  OF  REPORT ;  AUDIT 

PURPOSE  OF  INPUT:  IMITIRL  POSITION 

AUDIT  TITLE  AID  10,;  REVIEW  OF  SOFT WAR I  DEVELOPMENT  ATCENTRAL 

AUDIT  TITLE  mMD  *.  WTIVIT1IS,  (Prolaet  No.  IFE-001A) 

RECOMMENDATION  Is  Wa  rteoMMd  that  tb*  CowptroHar  •*  «>•  ani* 

S.f.^  diraet  tba  Military  Dapartwanta .  tba  Marina  Corpa .  And  tha  Dafanaa 

•ganctaa  tc  davalop  and  iwplawant  a  ain*la 

•eftwaro  davalopwant  and  waintananea  that  coapliaa  with  DoD  7»ao.»  ». 
•Dapart-nt  0,  D.fana.  Aceountin <  Manual.'  Fabruary  1BBB. 

DLA  COMMENTS:  Coneur.  DLA  ia  eisrrantly  addraaain*  tbia  Aaaua.  *b#  . 

Configuration  Managaaant  Auteawtad  Syata.  *on‘*in*  will  Jupp^rt 

cbanga  roquoato  which  support*  cost  Accounting.  Tho  coat  data  l  pp 

tba  eoncapt#  dapictad  in  DoD  7220. 9-M. 


P1U?S1Aetion  ia  ongoing.  E.tiwatad  Co«plation  Data:  30  Saptaasbar  IBBS 
(  )  Action  is  eonaidarad  eompltta. 

RECOMMENDATION  MONETARY  BENEFITS:  (WHERE  APPLICABLE) 

DLA  COMMENTS: 

ESTIMATED  REALIZATION  DATE: 

AMOUNT  REALIZED: 

DATE  REALIZED; 

INTERVAL  MANAGEMENT  COITTROL  WEAKNESS; 

(  )  Nonconcur.  (Bationala  »uat  ba  docuwantad  and  »aintainad  with 
your  copy  of  tba  raaponsa.) 

(X)  Concur;  howavar ,  waaknass  is  not  consid arad  aatarial.  (Bationala 
wust  ba  documantad  and  maintainad  with  your  copy  of  tba  raaponsa.) 

(  )  Concur;  waaknass  ia  auitarial  and  will  bo  raportad  in  tba  PLA 
Annual  Statowant  of  Aoauranca. 

ACTION  OFFICER:  Ponna  McCloud,  DLA-ZSS ,  x44326,  27  Jan  92 

PSE  REVIEW/ APPROVAL :  Bobby  L.  Parsons .  DLA-ZD,  Daputy  Ixocutiva  Piraetor , 

Offica  of  Information  Syatama  and  Toebnoiogy,  x46257, 
31  Jan  92 

DLA  APPROVAL:  Bo  Ion  T.  McCoy,  Doputy  Cowptrollor 
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MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


roUUT  3  of  9  PATE  OF  POSITIOP:  •  IUr  02 

TYPE  OF  REPORT ;  AUDIT 

PURPOSE  OF  XBPUT:  IBITXAL  POSITIOP 

AUDIT  TITLE  AHD  BO.;  REVIEW  OF  SOFTWARE  DEVELOPMEPT  AT  CEPTBAL 

BASIS!  ACTIVITIES.  (Project  Ho.  1FE-0018) 

FIPDIIIO  B:  tenMiMDt  O t  loft«tr«  Changed.  Our  review  of  350  software 
changes  showed  that  oil  emre  valid  requirements*  *21  changes  were  planned 
and  sot  user’s  nttdf,  and  planned  objectives  were  acbiovod.  Howvir,  150 
changes  exceeded  their  estimated  completion  dates*  required  coat  analyses 
vara  not  prepared  for  240  changes*  coata  were  not  measured  and  trackad. 
alapaad  time  mi  not  effectively  measured  and  trackad  for  00  cbangaa.  and 
identified  benefits  valued  at  16.5  alllion  vara  not  achiavad. 

PLA  CONCEPTS:  Concur.  PLA  la  currently  developing  and  lapleaen ting 
Software  aanageaent  toola.  PLA  baa  baan  utilising  Program  Management  toola 
and  aovlng  toward*  standardising  a  tool  aat.  Program  management  toola  taka 
cart  of  software  for  tba  long  term  planning  tracking,  scheduling  coat 
factora  and  conf iguration  management. 

1STERPAL  MAPAOEMENT  C0PTB0L  WEAXPESS; 

(  )  Bonconcur  (Rationale  muat  be  documented  and  maintained  with  your  copy 
of  the  reaponae. ) 

it)  Concur:  however,  wea knee*  ia  not  coneidered  material .  (Rationale  muat 
Be  documented  and  maintained  with  your  eopy  of  the  reaponae.) 

(  )  Concur;  weakneea  ia  material  and  will  be  reported  in  the  DLA 
Annual  Statement  of  Aaaurance. 

ACT I OP  OFFICER :  Donne  McCloud.  DLA-ZSS.  x44326.  27  Jan  02 

PSE  BEV I EW/ APPROVAL :  Bobby  L.  Paraona ,  DLA-ZD,  Deputy  Executive  Director* 

Office  of  Information  Syoteme  and  Technology.  x46257, 
31  Jan  02 

DLA  APPROVAL:  Helen  T.  McCoy.  Deputy  Comptroller 
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MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


rOKMUT  4  of  o 

TTPI  or  NEPORT:  AUDIT 

ruirost  or  input:  initial  position 

AUDIT  TITLE  AND  NO.:  REVIEW  OF  SOH 


DATE  OF  POSITION:  0  Mar  02 


REVIEW  or  SOFTWARE  DEVELOPMENT  AT  CENTRAL 
DESIGN  ACTIVITIES,  (Projact  No.  XPE-001B) 


RECOMMENDATION  2;  Do  r«r&«M»d  that  tb#  Diractor  for  Pafanaa  Information, 
Aaaiatant  Sacratary  of  Dafanaa  (Command,  Control,  Communication#  and 
InuUlf«nct)  ,  roquiro  th«  Military  Dapartmanta ,  Marino  Ccrpa ,  and  tno 

Dofonaa  aganciaa  to  uaa  a  standard  projact  managamant  ayatam. 

DLA  COMMENTS :  Concur . 

DISPOSITION; 

(  )  Action  ia  ongoing.  Eatimatad  Completion  Data; 

(X)  Action  ia  eonaidarod  eomplata. 

RECOIMENDATJON  MONETART  BENEFITS:  (WHERE  APPLICABLE) 

DLA  COMMENTS: 

ESTIMATED  REALIZATION  DATE: 

AMOUNT  REALIZED: 

DATE  REALIZED: 

INTERNAL  MANAGEMENT  CONTROL  WEAKNESS: 

(  >  Nonconcur.  (Rational#  muat  ba  doeumentad  and  malntainad  with 
your  copy  of  tha  raaponaa  ) 

(X)  Concur;  however ,  weakneat  ia  not  conaidarad  material.  (Rationale 
muat  ba  documented  and  maintained  with  your  copy  of  tha  raaponaa . ) 

(  )  Concur;  weakneaa  ia  material  and  will  ba  raportad  in  tha  DLA 
Annual  Statament  of  Aaauranca. 

ACTION  OFFICER:  Donna  McCloud.  DLA-ZSS.  *44320.  27  Jan  02 

PEE  REVIEW/ APPROVAL:  Nobby  L.  Paraona ,  DLA-ZD,  Daputy  Executive  Director, 

Offica  of  Information  Syataaa  and  Tachnology.  *46237, 
31  Jan  02 

DLA  APPROVAL:  Helen  T.  McCoy.  Daputy  Comptrollar 
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MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


rOUUT  »  of  •  PATE  or  rOSITXOE:  e  Iter  03 

ttti  or  uro*T:  audit 

PURPOSE  OF  INPUT :  INITIAL  P0SXT10H 

AUDIT  TITLE  AND  VO.:  REVIEW  OF  SOFTWARE  DEVELOPMENT  AT  CENTRAL 

DESIGN  ACTIVITIES,  (Project  Vo.  IFE-0016) 

RECOMMEND  AT  I  ON  S:  We  McoMtnd  that  the  Comptroller#  of  the  Military 
S«p*riMntv.  the  Fiscal  Director  of  tbs  Marins  Corps,  and  tbs  Plroctor, 
Psfsnss  Logistles  Agency,  establish  procsdurss  to  follow  up  on  idontifiod 
oconoaic  benefit*  associatod  with  Noftwars  changes  to  onsuro  that  tboss 
bans fits  ars  achieved. 

DLA  COMMENTS:  Concur.  DLA  has  procsdurss  to  traes  softwars  change 
requirements  through  product  dsl ivory  to  aid  in  Justifying  tbs  fulfillmsnt 
of  dsfinsd  bsnsfits.  DLA  doss  adjust  operating  budgets  of  its  field 
activities  to  reflect  savings  froa  invsstaent  in  Autoaatsd  Information 

Systsas . 

DISPOSITION: 

(  )  Action  is  ongoing.  Estimated  Completion  Date: 

(X)  Action  la  considered  complete. 


RECOMMENDATION  MONETARY  BENEFITS; 
DLA  COMMENTS: 

ESTIMATED  REALIZATION  DATE: 
AMOUNT  REALIZED: 

DATE  REALIZED: 


(WHERE  APPLICABLE) 


INTERNAL  MANAGEMENT  CONTROL  WEAKNESS: 

(  )  Nonconcur.  (Rationale  must  be  documented  and  maintained  with 
your  copy  of  the  response.) 

(X)  Concur;  however,  weakness  ia  not  conaidered  material.  (Rationale 
must  be  documented  and  s*intalned  with  your  copy  of  the  response.) 

(  )  Concur;  weakness  is  material  and  will  be  reported  in  the  DLA 
Annual  Statement  of  Assurance. 

ACTION  OFFICER:  Donna  McCloud,  DLA-ZSS .  *44320,  27  Jan  02 

PSE  REVIEW/ APPROVAL:  Bobby  L.  Parsons ,  DLA-ZD ,  Deputy  Executive  Director, 

Office  of  Information  Systems  and  Technology,  *46257. 
31  Jan  02 

DLA  APPROVAL:  Helen  T.  McCoy,  Deputy  Comptroller 
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MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


rosiuT  e  of  » 


PATE  or  rOSITIO*;  0  Iter  02 


TYTI  OF  PirOBT;  AUDIT 


PURPOSE  OF  INPUT:  INITIAL  POSITION 

AUDIT  TITLE  AND  NO.  :  REVIEW  OF  SOFTWARE  DEVELOPMENT  AT  CENTRAL 

MSI ON  ACTIVITIES,  (Project  No,  lFE-OQie) 


NECOtMEND AT  1  ON  4a;  •*  recommend  the t  the  Commandant  of  the  Marino  Corps; 

lb*  Army.  Director  of  Inf ernation  Systems  for  Command,  Control, 

Comuni  cations  and  Computers;  the  Navy  Commanding  Officer,  Naval  Information 
Systems  Management  Center;  the  Air  Fores  Deputy  Chief  of  Staff  Command. 
Control,  Communication*  and  Computers;  and  the  Director,  Defense  Logistics 
Agency  require  that  management  prepare  and  us*  cost  analysts  in  the  approval 
process  for  software  change  requests  as  required  by  DoD  Instruction  ™41.3, 
'Economic  Analysis  Program  Evaluation  for  Resource  Management,*  October  IS, 
1972. 


DLA  COMMENTS:  Concur,  DLAR  4730. 2)  establishes  a  more  stringent  process  for 
eost  analysis  in  the  review  and  approval  process  for  a  requirement. 

DISPOSITION: 

(  )  Action  is  ongoing.  Estimated  Completion  Date: 

(X)  Action  is  considered  complete. 

RECOIMENDATION  MONETARY  BENEFITS:  (WHERE  APPLICABLE) 

DLA  COMMENTS: 

ESTIMATED  REALIZATION  DATE: 

AMOUNT  REALIZED: 

DATE  REALIZED: 

INTERNAL  MANAGEMENT  CONTROL  WEAKNESS: 

(  )  Nonconcur.  (Rational#  must  be  documented  and  maintained  with 
your  copy  of  the  response.) 

(X)  Concur;  however,  weakness  is  not  considered  material.  (Rationale 
must  be  documented  and  maintained  with  your  copy  of  the  response.) 

(  )  Concur;  weakness  is  material  and  will  be  reported  in  the  DLA 
Annual  Statement  of  Assurance. 

ACTION  OFFICER:  Donna  McCloud,  DLA-ZSS,  x44326 ,  27  Jan  92 

pfg  EXVIEW/ APPROVAL:  Bobby  L.  Parsons,  DLA -ZD .  Deputy  Executive  Director, 

Office  of  Information  Systems  and  Technology,  *49257, 
31  Jan  92 

DLA  APPROVAL:  Helen  T.  McCoy,  Deputy  Comptroller 


Enel  v/at tachment 

I  — —  — 
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MANAGEMENT  COMMENTS;  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


UfcFENaE  LOGISTICS  AGENCY 

HEADQUARTERS 
CAMERON  STATION 
ALEXANDRIA  VIRGINIA  «*04-*l00 


DLAR  4730  3 


DLA  REGULATION 
NO.  47303 


DLA-Z 
20  Feb  91 


DEFENSE  LOGISTICS  AGENCY 

AUTOMATED  DATA  PROCESSING/TELECOMMUNICATION  (ADP/T) 
CONFIGURATION  MANAGEMENT  PROGRAM 

(Supplementation  is  prohibited.) 

It  PURPOSE  AND  SCOPE.  This  E>LAR  imple- 
Kents  the  DoD  Directive  5000.1,  Major  and  Non- 
Major  Defense  Acquisition  Programs,  and  DoD 
Directive  5010.19,  DoD  Configuration  Manage¬ 
ment  Program,  by  prescribing  policy  and  assigning 
responsibilities  for  Defense  Logistics  Agency's 
ADP/T  Configuration  Management  (CM)  Program. 
This  regulation  applies  to  HQ  DLA,  all  the  field  ac¬ 
tivities,  and  supporting  contractors  responsible  for 
the  implementation  of  CM.  To  ensure  that  CM  is 
applied  to  all  systems,  this  regulation  shall  be  used 
throughout  the  system's  life  cycle  by  all  activities 
responsible  for  developing  and  managing  current 
aad  modernization  systems.  Appropriate 
provisions  for  CM  shall  be  included  in  contracts  or 
Government  written  agreements  such  as  Request 
for  Proposals  (RFPs)  and  Program  Management 
Plans.  Program  Managers  and  AXS  Administrators 
shall  use  CM  during  acquisition  to  assist  in  achiev¬ 
ing  the  required  system  performance  and  in 
documenting  the  design  that  satisfies  the  system's 
management,  technical,  and  functional  require¬ 
ments.  CM  will  be  used  during  deployment  and 
operation  to  control  and  account  for  the  functional 
and  physical  characteristics  of  systems  to  ensure 
that  the  systems  are  responsive  to  operational 
needs;  to  effectively  satisfy  functional  require¬ 
ments;  and  to  ensure  that  CM  can  be  efficiently  sup¬ 
ported.  CM  anil  be  utilized  to  identify,  control, 
account  for,  and  audit  the  functional  and  physical 
characteristics  of  systems,  software,  equipment, 
support  equipment/software,  aad  other  designated 
hems  developed,  deployed,  operated,  and  sup¬ 
ported  by  DLA. 


L  REFERENCES 

A.  DoD  Directive  7920.1,  Life-Cycle  Management 
of  Automated  Information  Systems  (AISs). 

B.  DoD  Instruction  7920.4,  Baselining  of 
Automated  Information  Systems  (AlS). 

C  DoD  Instruction  7920.2,  Automated  Informa¬ 
tion  System  (AlS)  Life-Cycle  Management  Review 
and  Milestone  Approval  Procedures. 

D.  MIL-STD-480B,  Configuration  Control- 
Engineering  Changes,  Deviations  and  Waivers. 

E.  MIL- STD-483 A,  Configuration  Management 
Practices  for  Systems,  Equipment,  Munitions,  and 
Computer  Programs. 

F.  DoD- STD-7935 A,  DoD  Automated  Informa¬ 
tion  Systems  (AlS)  Documentation  Standards. 

G.  DLAR  4700.1,  Administration  of  the  DLA 
Automated  Data  Processing/Telecommunications 
(ADP/T)  Program. 

H.  DLAR  4730.1,  Life  Cycle  Management  (LCM) 
of  DLA  Automated  Information  System  (AlS). 

L  DLAR  4730.6,  Management  of  Central  Design 
Activity  (CDA)  Project  Development  Plans  (PDF). 

J.  MIL- STD-482,  Configuration  Status  Account¬ 
ing  Data  Elements  and  Related  Features. 

K.  MIL-STD-1521B,  Technical  Reviews  and 
Audits  for  Systems,  Equipments,  end  Computer 
Software. 

L.  DLA  Configuration  Management  Plan. 

M.  FIR  MR  20119,  U.S.  General  Services  Ad¬ 
ministration  IRM  Review  Handbook. 

N.  DLAM  5200.1,  ADP  Security  Manual. 


HI.  POLICY 

A.  CM  involve!  the  systematic  application  of  basic 
system  engineering  management  principles  which 
are  divided  into  the  four  basic  functions:  eoefigura- 


This  DLAR  supersedes  DLAR  47303,  26  Apr  85  and  DLAR  47203, 13  Jfuo  86. 
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lio»  identification,  configuration  control,  configura¬ 
tion  s»diu,  and  configuration  status  accounting. 
CM  practice*  mad  procedure*  will  be  applied  in  ac¬ 
cordance  with  the  detailed  requirement*  of  this 
regulation  to  all  system*,  system  segmcaU,  software 
and  hardware  (including  firmware)  configuration 
ttrai  (CIs),  telecommunication*,  and  other  desig¬ 
nated  item*  developed  partially  or  wholly  with 
Government  funding.  Industry  and  Government 
afeacies  shall  adhere  to  the  following  management 
and  documentation  policies  as  applicable. 

X,  Configuration  Management  of  all  AISs,  in¬ 
cluding  nnique  systems,  being  maintained  or  mod¬ 
ernized  shall  be  administered  in  accordance  with 
the  requirement*  of  thi*  regulation. 

1.  DoD  Directive*  and  appropriate  Military 
Standard*  for  weapon  systems  shall  be  followed  to 
the  extent  feasible  for  a  disciplined  ADP/T  environ¬ 
ment. 

3.  System  life  cycle  documentation  shall  be 
prepared  in  accordance  with  PoP -STD-7935 A. 
The  documentation  guidelines  in  DoD-STD-2167A, 
Defense  System  Softwtre  Development,  cannot  be 
gyiityj.il  as  a  substitution. 

4.  All  AlS  new  requirements,  system  change  rc- 
qaests,  technology  work  requests,  eagineering 
change  proposals,  specification  change  notices, 
deviation*  and  waiver*  mu*t  be  processed  and  ap¬ 
proved  in  accordance  with  the  procedure*  and  CM 
organization  established  is  thi*  regulation. 

5.  All  Program  Managers  of  modernization 
programs,  defined  as  major  system*  in  DLAR  4730.1 
which  require  Office  of  Secretary  of  Defense  ap¬ 
proval,  shall  prepare  a  Progr*®  CM  Pima  in  accord¬ 
ance  with  the  DLA  CM  Plat  and  this  regulation. 

d.  AlS  Administrators  and  Project  Managers  of 
existing  AIS*  and  AlS  modernization  projects  shall 
ntUize  the  DLA  CM  Plan. 

7.  All  AISs  undergoing  development  or  modern¬ 
ization  shall  have  sequentially  established  function¬ 
al,  allocated,  and  product  baselines  at  described  in 
paragraph  VII1B.  The  CDA  shall  maintaia  the  ap¬ 
proved  AIS  product  baseline  and  iu  changes  Utiliz¬ 
ing  CM. 

g.  Approved  reporting  procedures,  as  stated  in 
this  regulation,  shall  be  used  by  DLA  to  submit  re¬ 
quirements  or  identify  problems  which  may  result  in 
changes  to  Standard  AIS*  (SAKS*),  modernization 
program*,  project*,  and  unique  systems.  An 


automated  CM  system  or  manual  form*  will  be  used 
a*  standard  methods  of  reporting.  A  consolidated 
ADP/T  Work  Request  (AWR)  form  shall  be  used  to 
manually  report  system  change*,  technology  chan- 
ges,  and  problem  trouble  report*.  All  internal  DLA 
request*  for  changes  to  existing  SAISs,  modern¬ 
ization  programs,  projects,  or  unique  systems  shall 
be  documented  on  an  AWR  form  as  a  System 
Change  Request  (SCR),  Technology  changes  shall 
be  documented  on  an  AWR  form  a*  a  Technology 
Work  Request  (TWR).  A  PreAnalysu  Requirement 
(PAR)  form  shall  be  utilized  by  Lead  principal  staff 
elements  (PSEt)  to  obtain  a  CDA  technical  opinion, 
cost,  and  time  estimate.  Problem  Trouble  Reports 
(PTR*)  for  software,  hardware  or  telecommunica¬ 
tion  problems  relating  to  AISs,  *h*U  be  submitted  to 
the  CDA  by  telephone  and  documented  on  an  AWR 
form  or  electronically  recorded  in  the  automated 
CM  System  by  the  CDA.  The  above  forms  shall  be 
prepared  in  accordance  with  the  DLA  CM  Plan. 
Request  for  Deviation  and  Waiver  (DAW)  form* 
shall  be  prepared  by  the  developing  CDA  or  con¬ 
tractor  la  accordance  with  MIL-STD-480B  and  the 
DLA  CM  Plan.  Engineering  Change  Proposal* 
(EC?*)  and  Specification  Change  Notices  (SCNs) 
shall  be  prepared  by  contractors  in  accordance  with 
MIL-STD-4S0B  and  the  DLA  CM  Plan. 

9.  The  DLA  standard  automated  CM  system 
shall  be  utilized  in  support  of  CM  for  DLA.  Other 
CM  system  justifications  must  be  submitted  to  the 
Office  of  Information  Systems  and  Technology 
pLA-Z)  for  approval. 

10.  DLA  shall  utilize  CM  to  nBdate  the  achieve-  i 
meal  of  functional  requirements  and  benefits  result¬ 
ing  from  .system  modification  or  modernization 
efforts.  The  achievement  of  functional  require¬ 
ments  will  be  traceable  and  validated  through 
eerie  wt  and  audits,  and  beat  fit*  identified  in  the 
•eoaomic  analysis  will  be  fdirnied,  according  to  the 

^schedule,  upon  acceptance  of  the  system. 

B.  CM  implementation  policies  shall  be  consistent 
with  the  objectives  of  the  program/projeet  and  iu 
life  cycle  phase.  As  system  life  cycle  phases  oceur, 
the  following  additional  CM  principles  ahall  be  ap¬ 
plied. 

1.  During  the  Concept  Development  Phase,  the 
identification  of  the  draft  system  functional  and  in¬ 
terface  characteristics  shall  be  eatered  in  the  CM 
system. 
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2.  During  (be  Detign  Phut,  Ibe  «yslem  function- 
«}  sod  interface  characteristics  shall  be  controlled 
ftftd  accounted  (or,  mad  tkc  draft  Cl  functional  and 
interface  characteristics  shall  be  identified. 

3.  During  the  Development  Phase,  the  sys¬ 
tem  and  Cl  functional  and  interface  charac¬ 
teristics  shall  be  controlled,  audited  and 
neeonated  for,  and  the  draft  Cl  detail  design 
characteristics  shall  be  identified  in  the  CM  sys¬ 
tem.  For  -contract  deliverable  CIs,  the 
Government's  CM  shall  control,  audit,  and  ac¬ 
count  for  the  delivered  detail  design  charac¬ 
teristics  which  will  be  received  at  the  end  of  this 
phase. 

4.  During  the  Deployment  Phase,  the  Cl  detail  % 
design  characteristics  shall  be  controlled,  audited, 
and  accounted  for;  the  system  and  Cl  functional  and 
interface  characteristics  shall  be  controlled;  and  the 
actual  configuration  of  CIs  delivered  in  the  DLA  en¬ 
vironment  shall  also  be  controlled  and  accounted 
for  in  the  CM  system. 

5.  During  the  Operations  Phsse,  the  system  and 
Q  functional,  interface,  detail  design  characteris¬ 
tics,  and  the  configuration  of  CIs  in  the  DLA  en¬ 
vironment  shall  be  controlled  and  accounted  for  in 
the  CM  system. 

C.  CM  policies  governing  other  agencies  interfac¬ 
ing  with  DLA  and  contractors  supporting  DLA  shall 
he  established  in  accordance  with  this  regulation 
and  supported  in  as  agreement  or  contract. 

1.  When  CIs  are  procured  and  operated  by  more 
than  one  agency,  agreement  must  be  made  to  desig¬ 
nate  the  agency  responsible  for  CM  and  to  define 
responsibilities  for  coordinated  CM  activities 
among  DLA  and  other  participating  agencies.  If 
DLA  is  designated  ns  the  agency  responsible  for 
CM,  the  agreement  must  adhere  to  this  regulation. 

2.  Each  contractor's  CM  Program/System  shall  be 
evaluated  to  assess  the  contractor's  ability  to  meat  the 
Government  CM  requirements,  such  ns  compatibility 
with  the  DLA  CM  automated  system,  and  conformance 
to  CM  documentation  and  reporting. 

3.  Each  contractor  should  be  able  Co  evaluate  and 
comment  on  those  CM  requirements  which  may  ad¬ 
versely  impact  the  contractor's  organizational  and 
functional  structure.  The  impacts  shall  be  iden¬ 
tified  by  the  contractors  in  the  CM  planning 
documentation  and  should  be  reviewed  and  resolved 
daring  source  selection. 
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4.  Tailoring,  of  the  implementation  by  contrac¬ 
tors,  of  the  CM  automated  system  is  acceptable  as 
long  as  the  requirements  of  this  regulation  are  ful¬ 
filled.  For  example,  contractors  should  want  to  cap* 
tare  more  detailed  information,  such  as  source  code 
changes,  during  the  Development  Phase  than  is  cur¬ 
rently  captured  in  the  automated  CM  system. 

IV.  DEFINITIONS.  See  enclosure  1  for  defini¬ 
tions. 

V.  BACKGROUND.  The  DLA  ADP/T  CM 
Program  was  established  to  institutionalize  CM  in 
DLA.  An  implementing  CM  regulation  was  re¬ 
quested  from  all  DoD  components  by  the  Office  of 
the  Secretary  or  Defense  (OSD).  DLA’s  strategy 
for  supporting  OSD's  request  was  authorized  in 
Feb  89  when  the  Information  Resources  Manage¬ 
ment  Official  approved  the  establishment  of  a  cor¬ 
porate  CM  system  with  distributed  CM  systems  for 
PSEs,  primary  level  field  activities  (PLFAs),  and 
Program  Managers.  This  strategy  will  allow  the 
agency  to  identify,  control,  account  for,  and  audit 
the  changes  in  current  systems  and  in  the  develop¬ 
ment  of  new  systems. 

VI.  SIGNIFICANT  CHANGES.  The  policies  in 
this  regulation  include  the  system  change  requests 
(SCR&)  and  problem  trouble  reports(s)  (PTRs), 
Technology  Work  Requests  (TWRs),  engineering 
change  proposals,  specification  change  notices, 
deviations,  and  waivers.  DLA  Form  S58, 
Automated  Data  Processing/Tciecommunicatioas 
Work  Request,  has  been  modified,  via  the  ADP/T 
Work  Request,  to  support  not  just  the  SCR,  but  the 
TWR  and  FTR.  In  addition,  a  new  DLA  Form  1799, 
Pre-Analysis  Requirement,  is  utilized  by  the  Lead 
FSE  to  obtain  technical  information  from  n  CD  A  on 
j  proposed  requirement.  The  review  and  approval 
process  for  SCRs  include  the  PSEs,  DLA-Z 
divisions,  working  groups,  and  configuration  con¬ 
trol  boards.  Technical  and  functional  managers  are 
making  derisions  together,  adding  to  the  quality  of 
derisions  and  supporting  total  quality  management 
in  the  Agency.  This  regulation  has  been  complete¬ 
ly  revised  and  should  be  reviewed  in  its  entirety. 

VII.  RESPONSIBILITIES 
A.  HQ  DLA 

1.  The  Assistant  Director,  Office  of  Information 
stems  and  Technology.  DLA  (DLA-Z).  as  the 
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pLA  Senior  Information  Resources  MsnaRcmeM 
(IRM)  Policy  Official  will; 

a.  Execute  tbc  CM  responsibilities  in  accord- 
••CC  with  applicable  DoD  |iidnce  a»d  thia 
regulation. 

b,  Program  ud  Budget  for  DLA  ADf/T  CM  as 


enquired. 

2,  Tbc  Chief,  Systems  Control  Branch,  PLA  Sys¬ 
tem  Management  Office  (DSMQL  Office  oflnfor^ 
pation  Systems  and  Technology.  (DSM.QrC)  will: 

a.  Establish  policies,  define  procedures,  imple- 
seat  and  support  the  automated  CM  system  for  tbe 


Mcutjr. 

b.  Be  responsible  for  tbe  overall  management 
of  tbe  automated  CM  system  software  and  tbe  data 
bases  used  for  tracking  changes  to  tbe  functional,  al¬ 
located,  and  product  configuration  baselines. 

c.  Manage  tbe  ADP  resources  hosting  the  CM 


system  software. 

d.  Provide  CM  support  and  approval  to  imple¬ 
ment  and  integrate  other  interface  tracking  systems 
into  the  overall  CM  system  design. 

e.  Establish  DLA  CM  network  management. 

f.  Be  responsible  for  the  DLA  CM  Program,  the 

DLA  CM  Plan,  the  DLA  AD? IT  CM  Regulation, 
nod  support  to  the  Corporate  Configuration  Control 
Board  (CCB).  ,  ,  t  , 

g.  Exercise  overall  direction  of  tbe  implemen- 

Utioo  of  the  CM  Program  and  ensures  that  the  prac¬ 
tices  and  procedures  tre  prudently  tailored  and 
applied.  ..... 

3.  The  Chief.  ATS  Administration  Branch, 
pLA  Systems  Management  Office  (DSMQLQf- 
|icc  of  Information  Systems  and  Technology, 
fDSMO-O)  will: 

n.  Review  all  requests  (SCR,  ECP,  SCN,  and 
DRW)  for  AIS/PM  CUss  1  and  AIS  Class  II  system 
changes  to  determine  the  system  impact,  policy  ad¬ 
herence  and  completeness  of  the  ease  as  docu- 


b.  Coordinate  with  the  requestor  tad  all  sup¬ 

port  staff  responsible  for  analysing  the  case  and 
provide  sUtus  input  on  the  request  in  the  automated 
CM  system.  .  ,  .  A__ 

c.  Provide  final  review  prior  to  submitting  AIS 
CUss  II  requests  to  the  CDA  for  implementation 
through  reserve  resources,  ns  available. 

d.  Be  responsible  for  ensuring  the  complete¬ 
ness  of  the  consolidated  Request  Impact  Analysis 
Report  which  tbe  functional  sponsor  will  utilize  to 


determine  if  the  requirement  is  acceptable  for  fur¬ 
ther  processing.  .  „  .  f  . 

e.  Prepare  administratively  and  jointly,  when 
the  requirement  is  received  from  the  Lead  Function¬ 
al  PSE,  Class  I  cases  for  the  working  groups  and 
chairs  the  AIS  Working  Croup. 

L  Input  requirement  and  contract  information, 
and  status  into  the  automated  CM  system. 

a  ProflTim  Managers.  Modernization  Program 
Offices.  DLA  Systems  Management  Office.  Officcof 
Information  Systems  and  Technology.  (PLA^ 
Z/DSMO))  will: 

a.  Review  all  requests  for  program  SCRs,  ECFs, 
SCNs,  Deviations,  and  Waivers  and  enter  them  into 
the  automated  CM  system. 

b.  Review  and  forward  program  Class  II  system 

changes  to  either  the  CDA  or  contractor  as  re¬ 
quired.  * 

c.  Forward  program  CUss  I  requests  to  the 
Sponsoring  FSE  Configuration  Manager  for  further 
processing. 

5,  The  Chief.  Systems  Operation!  Division. 
Office  of  Information  Svstemi  and  Technology, 
fPLA-ZO)  will: 

a.  Participate  in  the  analysis  of  CUss  I  cases  to( 
determine  the  impact  of  facility  and  operational  site 
requirements. 

b.  Forwarded  results  to  DSMO-O  for  the  con¬ 
solidated  case  impact  analysis. 

c.  Be  responsible  for  maintaining  the  status  of 
site  information  in  automated  systems  and  providing 
information  on  current  cuvironmenti  for  AISs, 
programs,  or  projects. 

d.  Input  requirement  and  contract  informa¬ 
tion  into- the  automated  CM  system  and  update  the 
tUtUS. 

6.  The  Chief.  Systems  Integration  Division, 
Office  of  information  Systems  and  Technology 
fDLA-Zn  will: 

a.  Review  the  analyses  on  all  requirements  to 
determine  the  impact  on  integration  and  technical 
architectures.  Telecommunications,  information 
engineering,  data  management,  technical  and  data 
standards,  and  decision  support  methodologies 
will  be  considered  U  reviewing  the  requirements. 

b.  Review  all  requests  for  Class  1  AWRs,  and 
requirement  and  contract  information  to  deter¬ 
mine  the  system  impact,  policy  adherence,  and 
completeness  of  the  case  as  documented. 
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c.  Be  responsible  for  overseeing  tbe  analysis, 
review  and  approval  processes,  development  and 
deployment  of  TWR  requirements.  Tbe  CDAs  will 
implement  and  maintain  tbe  TWR  status  informa* 
Ison  in  tbe  automated  CM  system. 

7.  Tbe  Chief.  PLA  ADP/T  Contracting  Office^ 
Office  of  Information  Systems  and  Technology 
fDACO)  will: 

a.  Ensure  that  appropriate  provisions  for  CM 
ore  included  in  contracts  for  all  Cls  throughout  their 
life  cycles. 

b.  Ensure  that  tbe  CM  responsibilities  of  tbe 
Government  and  contractor  are  clearly  defined  and 
Identified  in  Contract  Data  Requirement  Lists. 

c.  Ensure  the  following  statement  is  present  in  % 
nil  new  system  or  program  specifications  containing 
CM  or  data  management  requirements:  ‘Configure* 
lion  Management  practices  and  procedures  will  be 
consistent  with  the  requirements  of  the  DLA 
ADP\T  Configuration  Management  Regulation  and 
DLA  CM  Plan." 

f .  The  Chief,  Information  Resources  Manage^ 
meet  Division.  Office  of  Information  Systems  and 
Technology.  (DLA-ZR)  will: 

a.  Ensure  that  policies  and  procedures  for  tbe 
CM  Program  are  being  established  consistent  with 
tbe  DLA  Information  Resource  Management 
Program  and  Total  Ouality  Management  guidelines. 

b.  Oversee  tbe  allocation  and  funding  assess* 
men!  on  AWRs  relating  to  AXSs  funded  with  the 
DLA*Z  ADP  account. 

9.  The  Heads  of  HQ  DLA  Principal  Staff  Ele* 
pents  (A.  C,  UC  U  O.  P,  Q,  S,  W,  and  Z\  will: 

a.  Establish  and  control  tbe  functionality  of  tbe 
changes  to  AlSs. 

b.  Approve  initially  tbe  processing  of  system 
changes  prior  to  being  given  consideration  for  im¬ 
plementation. 

c.  Designates  Configuration  Manager  who  will 

participate  in  tbe  AIS  Working  Group,  tbe  AIS 
CCB,  and  tbe  Corporate  CCB  nt  applicable  to  sup¬ 
port  tbe  process  established  for  controlling  nnd  ap¬ 
proving  system  changes. 

d.  Prepare  general  functional  requirements  nt 
needed  to  fulfill  assigned  missions  and  approve/dis- 
approve  tbe  functional  requirements  aspects  of  all 
AWRs  relating  to  assigned  functional  respon¬ 
sibility.  Functional  requirements  as  defined  on  na 
AWR  must  be  thoroughly  and  clearly  stated  with 
volume  and  transaction  dats  needed  to  support  the 


development  of  an  estiir  ted  cost  impact.  The 
benefits  from  the  functional  requirements  must  be 
stated  in  terms  of  cost,  resource  savings,  and  func¬ 
tional  benefits. 

c.  Coordinate  sponsored  AWRs  with  all  PSEs 
having  related  policy  responsibilities  and  comments 
shall  be  obtained  from  those  PLFAs  that  will  be  af¬ 
fected  because  of  development  resource  require¬ 
ments  or  changed  operational  requirements. 

f.  Ensure  that  the  functional  policy  documenta¬ 
tion  supports  approved  AWRs  and  is  timely  updated 
to  support  changes. 

g.  Prepare  a  semiannual  Functional  Priority 
f  frt  (FPL)  by  tbe  Lead  Functional  PSE  based  on  tbe 
relative  priority  of  AWRs  within  an  assigned  func¬ 
tional  area  and  will  be  controlled  using  the 
automated  CM  system.  The  FPL  will  be  consistent 
with  tbe  DLA  established  priorities  and  the  FSE 
functional  initiatives  defined  in  response  to  the  AIS 
strategic  planning  process.  Differences  may  exist 
between  the  FPL  and  functional  Initiatives  in  order 
to  implement  unplanned  emergency  or  mandated  re¬ 
quirements  which  cannot  be  delayed  until  the  next 
FPL  or  strategic  plan  is  prepared. 

k.  Assign  priorities  on  the  FPL  list  by  the  Lead 
Functional  PSE. 

i.  Provide  the  FPL  to  DLA-Z  for  implementa¬ 
tion  and  resourcing  through  periodic  reviews  of 
workloads,  priorities,  and  scheduling  in  accordance 
with  the  PDP  procedures  outlined  in  DLAR  4730.6. 

j.  Provide  the  approved  general  functional  re¬ 
quirements  and  functional  benefit  estimates  to 
DLA-Z  for  tbe  CDA  to  perform  AWR  analysts  and 
development. 

k.  Approvt/di&approve  functional  changes  and 
detailed  functional  requirements  developed  by  the 
CDAs  to  support  approved  AWRs. 

L  Submit  Lead  Functional  FSE  approved  re¬ 
quests  to  DLA-Z  in  order  to  obtain  use  of  CDA 
resources  already  reserved  during  the  PDF  process 
to  implement  Class  II  system  changes. 

m.  Identify,  in  coordination  with  the  CDA  and 
the  AIS  administrator,  those  AWRs  that  will  require 
formal  functional  testing  and/or  initial  operational 
testing. 

a.  Provide  functional  expertise  to  the  CDA  as 
needed  during  functions!  test  plan  development  and 
functional  testing. 

o.  Certify  the  adequacy  of  functional  tests  for 
all  mqjor  modifications. 
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p  Support,  with  function*!  expertise,  initial 
operational  teau  associated  with  an  AWR  which  will 
be  monitored,  nnd  approved  or  disapproved  baaed 
•a  the  results  of  the  lest. 

q.  Provide  guidance  to  PLFAi  and  CD  As  on 
functional  (raining  needs  for  implementation  of  sys¬ 
tem  changes. 

B.  Field  Activities 

1.  The  Headt.  Primary  Level  Field  Activities 
fPLFAs1).  (except  CDAsj  will: 

a.  Be  responsible  for  implementing  CM  for  the 
ADP/T  configuration  items  under  their  respective 
cognizance. 

b.  Exercise  centralized  direction  and  control 
over  their  respective  programs/projects  to  ensure 
uniform  compliance  with  this  regulation  and  be 
responsible  for  maintenance,  control,  and  accuracy 
of  their  respective  coafiguration  data,  systems,  and 
equipment. 

c.  Designate  a  Configuration  Manager  to  con¬ 
trol  and  manage  the  CM  reporting  procedures  for 
submission  of  AWRs  to  the  CDA  Configuration 
Manager  and  PTRs  to  the  responsible  CDA. 

d.  Implement  only  changes  approved  by  func¬ 
tional'  PSEs  and  released  by  the  responsible  CDA 
for  implementation. 

e.  Perform  situation  analysis  of  emergency  sys¬ 
tem  deficiencies.  If  system  deficiencies  are  due  to 
functional  and/or  CDA  software,  the  PLFA  should 
develop  a  recommended  solution(s)  to  return  the 
system  to  operational  status  and  submit  appropriate 
Problem  Trouble  Report  (hot  line  or  warm  line)  to 
the  CDA. 

2.  The  Central  Design  AgtMUei  wfll: 

a.  Implement  this  regulation  by  exercising  the 
specific  responsibilities  listed  below  and  assigned  in 
paragraph  VII 1. 

b.  Be  responsible  for  ensuring  that  all  im¬ 
plementing  documents  from  CDA  satellites  are  con¬ 
sistent  with  their  respective  command  level 
documents,  and  this  regulation. 

c.  Ensure  that  no  unauthorized  coafiguration 
changes  are  made  to  CIs  under  their  cognizance. 

d.  Establish  software  configuration  control 
within  the  CDA  responsible  for  providing  impact 
analysis  on  software  SCRs  being  reviewed  by  the< 
A1S  or  Corporate  CCB,  and  reviewiag  contractor 
ECPs  which  contain  changes  to  the  approved  con¬ 
figuration  identification  of  n  computer  software 


configuration  item  (CSC1)  under  development, 
delivered  or  to  be  delivered. 

e.  Perform  a  preanalysis,  it  the  request  of  the 
Lead  Functional  PSE,  on  the  proposed  requirement 
which  includes  estimated  cost,  time,  end  feasibility 
of  implementation.  The  CDA  will  Jipdate  the 
manual  or  automated  Preanalysis  Requirement 
form  with  the  nbove  information  within  10  d«ys  after 
receipt.  The  Lead  Functional  PSE  will  only  utilize 
the  preanalysis  information  to  aid  in  assessing  the 
requirement  prior  to  submitting  it  to  DLA-Z.  The 
CDA  will  not  be  held  accountable  for  preanalysis  es¬ 
timates. 

f.  Conduct  a  technical  analysis  simultaneously 
with  DLA-Z  divisions,  at  the  request  of  DLA-Z,  of 
the  genera)  functional  requirements  as  stated  on  the 
AWR,  and  provide  within  30  days  a  preliminary  es¬ 
timate  of  development  and  implementation 
resource  requirements  and  n  coat  impact  assess¬ 
ment. 

g.  Review  the  AWR  for  integration  impact 
based  on  the  business  area  analysis,  architectural 
standards  established  by  DLA-Z1,  the  functional  ar¬ 
chitecture,  and  project(s)  identified. 

h.  Review  the  change  requests  on  nil  proposed 
software  changes  which  interface  or  impact  other 
AIS  software  systems. 

i.  Identify  consolidation  opportunities  among 
scheduled  and  new  AWRs  for  consideration  during 
PDP  updates.  Consolidation  moat  be  limited  so  as 
not  to  interfere  with  required  implementation  dates. 

j.  Prepare  detailed  functional  requirements  for 
the  appropriate  AWRs  after  an  AWR  has  been  ap¬ 
proved  and  placed  on  the  CDA  Project  Develop¬ 
ment  Plan, 

k.  Prepare  the  hardware/software  and  telecom¬ 
munications  design,  code  the  programs  for  ap¬ 
proved  system  changes,  and  coor climate  with  PLFAs 
during  development. 

l.  Ensure  that  ADP  and  functional  documenta¬ 
tion  conforms  to  DoD  and  DLA  standards,  especial¬ 
ly  DoD- STD-7935 A,  and  is  prepared  and 
maintained  electronically  and  in  hard  copy. 

m. }  Ensytrg  Jhnt  security  safeguard*  required  in 
^^cor  dance  with  DLAM  5200.1  will  he  iacor- 
iJoratedrinVM^W^  changes  before, they  are 

released.  The  AWR;  ECP,  er.DJtW^mpect  state- 
aPcnt  will  include  certification  that  the. proposed 
system  design,  if  applicable,  has  been  reviewed  by 
the  cognisant  AIS  ADP  System  Security  Rcpre- 
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representative.  The  chairperson  will  schedule  and 
chair  the  quarterly  meetings,  As  appropriate,  the 
chairperson  of  the  Corporate  CCB  has  the 
authority  and  responsibility  to  act  immediately  and 
aay  call  emergency  meetings  of  the  Corporate 
CCB. 

d.  Make  decisions  within  the  bonadaries  of  the 
established  agency  priorities  on  major  changes  to 
the  DLA  configuration  baselines. 

c.  Prepare  the  Corporate  CCB  Directive 
which  is  ased  by  the  ehairperaoa  to  notify  Con¬ 
figuration  Managers,  aad  DACO  If  aeqnisition  is 
required,  of  Corporate  CCB  decisions.  Corporate 
CCB  Directives  will  be  published  with  the  minutes 
of  the  Corporate  CCB  meetings  aad  aeat  by 
electronic  or  routine  mail  to  members. 

f.  Evaluate  all  proposed  change  requests 
which  impact  AISs  of  more  than  one  Lend  Func¬ 
tions)  FSE  responsibility;  establish  a  new  AIS;  cost 
Is  S15  million  in  S  year  or  $75  million  daring  the 
program/project;  contain  a  configuration  item  pur¬ 
chase  which  is  global  in  nature;  or  are  defined  as  a 
special  interest  case.  The  quorum  for  each  as¬ 
sembly  of  the  Corporate  CCB  meetings  will  consist 
of  all  voting  members  whose  ares  is  impacted  by 
the  change  or  has  a  special  interest  in  the  change. 
Every  member  of  the  Corporate  CCB  affected  by 
the  change  is  designated  by  the  chairperson  as 
being  required  to  attend  and  evaluate  the  change 
requests. 

g.  Receive  a  status  accounting  of  Government 
proposed  or  contractor  proposed  changes  dealing 
with  local  unique  site  applications  whieh  wilt  be 
placed  under  configuration  management. 

h.  Consist  of  voting  members  which  are  Heads 
•f  the  following  DLA  Offices  and  Directorates  or 
a  designated  representative:  Directorate  of  Con¬ 
tract  Management  (DLA-A);  Office  of  Comp¬ 
troller  (DLA-C);  Office  of  Command  Security 
(DLA -I);  Office  of  Civilian  Personnel  (DLA-JC); 
Office  of  Policy  and  Plans  (DLA-L);  Directorate 
of  Snpply  Operations  (DLA-O);  Directorate  of 
Contracting  (DLA-P);  Directorate  of  Qnality  As¬ 
surance  (DLA-Q);  Directorate  of  Technical  and 
Logistics  Services  (DLA-S);  the  Office  of  Installa¬ 
tion  Services  and  Eavironmenta)  Protection 
(DLA-W);  and  the  Office  of  Information  Systems 
nnd  Technology  (DLA-Z),  ns  the  chairperson. 

».  Have  the  members  vote  on  "major*  changes 
ns  appropriate  and  within  assigned  functional, 


technical,  and  support  responsibilities.  The 
majority  vote  is  the  ruling  dccisioa  unless  there  is 
an  unresotvable  issue,  then  the  chairperson  of  the 
CCB  may  recommend  alternative  strategies  based 
os  agency  priorities  and  implementation  resour¬ 
ces,  or  refer  the  decision  to  the  Deputy  Director. 
If  a  majority  vote  of  the  Corporate  CCB  members 
participating  it  a  case  review  do  not  accept  alter¬ 
native  recommendations  of  the  chairperson,  the 
issue  wit)  be  elevated  to  the  Deputy  Director  for 
final  approval. 

j.  Have  DLA  contractors,  the  Military  Ser- 
vices,  or  designated  PSEs  and  PLFAs  attend  meet¬ 
ings  as  required  and  participate  as  monvoters. 

,k.  Allow  for  new  members  to  be  appointed  to 
the  Corporate  CCB  as  requested  by  organisations 
or  members  of  the  board  and  approved  based  on 
majority  vote  of  the  Corporate  CCB.  Consistency 
in  board  membership  and  in  the  chairperson  as¬ 
signment  must  be  maintained  in  order  to  avoid 
losing  continuity  in  CCB  operations. 

4.  The  AlS/Progrtm  CCB  (referred  to  ns  AIS 
£21  will: 

a.  Act  as  a  subboard  to  the  Corporate  CCB 
responsible  for  CM  of  existing  AISs,  of  supporting 
AIS  projects,  nnd  of  AIS  related  modernisation 
programs. 

b.  Have  eoehairpersons  of  the  AIS  CCB  who 
are  the  Lead  Functional  PSE  aad  DLA-Z  repre¬ 
sentatives.  They  will  schedule  aad  chair  the  meet¬ 
ings,  record  final  decisions,  aad  make  the  final 
decision  on  unresolvable  issues  that  are  major 
changes  to  the  AIS  configuration  baselines.  The 
functions!  PSE  is  responsible  for  ensuring  thst  re¬ 
quirements  arc  accurately  defined,  justified,  and 
functionally  prioritized.  The  DLA-Z  cochairper¬ 
son  will  address  technical  issues  surrounding  the 
implementation  of  the  requirement  aad  allocation 
of  cost  nnd  resource  requirements. 

c.  Make  decisions  on  eases  within  the  assigned 
responsibility  of  a  Lead  Techuical/Puactional  PSE 
aad  Sponsoring  PSEs. 

d.  Delegate  authority  to  the  AIS  or  Program 
Working  Groups  to  approve  or  disapprove  Class  X 
changes  which  meet  n  specific  threshold,  such  as 
changes  requiring  leu  than  6  man-months  of  CDA 
effort.  Program  Working  Groups  of  modern¬ 
ization  programs  may  be  delegated  authority  and 
specific  guidelines  to  approve  or  disapprove  chan¬ 
ges  against  the  approved  system  specification  for 
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Ut  program.  All  delegated  authority  remain,  the 
responsibility  of  tbe  AIS  CCB. 

e.  Review  status  reports  on  til  decisions  msde 
by  Working  Groups  *nd  ensure  information  is 
recorded  in  the  automated  CM  system.  Status 
reports  most  be  submitted  at  least  qnarterly  to  tbe 
AIS  CCB  for  review. 

t  Be  required  to  provide  status  f  eports  as  re¬ 
quested  by  tbe  Corporate  CCB  chairperson. 

g.  Evaluate  all  proposed  ehange  requests,  if 
sot  delegated  to  the  Working  Group,  which  meet 
(he  Class  I  criteria  ns  defined  in  enclosure  2.  The 
quorum  for  each  assembly  of  the  AIS  CCB  meet- 
lugs  will  coasist  of  all  voting  members  whose  area 
is  impacted  by  tbe  ehange  or  has  a  special  interest  . 
in  the  change.  Every  member  of  the  AIS  CCB  af¬ 
fected  by  the  change  is  designated  by  the  cochair¬ 
persons  as  being  required  to  attend  nnd  evaluate 
the  change  requests. 

h.  Convene  the  AIS  CCB  meetings  on  a 
quarterly  basis  or  as  required  to  support  the  needs 
of  tbe  AIS.  As  appropriate,  tbe  cochairpersons  of 
the  AIS  CCB  have  the  authority  and  responsibility 
to  act  immediately  and  may  call  emergency  meet¬ 
ings. 

i.  Prepare  the  AIS  CCB  Directive  which  is 
used  by  the  chairpersons  to  notify  Configuration 
Managers,  and  DACO  if  acquisition  is  required,  of 
AIS  CCB  decisions.  AIS  CCB  Directives  will  be 
published  with  the  minutes  of  the  AIS  CCB  meet¬ 
ings  and  sent  by  electronic  or  routine  mall  to  mem¬ 
bers. 

j.  Consist  of  voting  members  of  the  AIS  CCB 
urhich  nre  representatives  from  DLA-Z,  the  Lead 
Functional  PSE,  Sponsoring  PSE,  end  other  sup¬ 
port  PSEs.  These  members  vote,  ns  determined  by 
(he  eocheirperaons,  on  ■major*  changes  to  AISs. 
The  majority  vote  is  the  ruling  decision  unless 
there  is  an  unresolvable  issue  which  the  co chair¬ 
persons  must  decide  or  submit  to  the  Corporate 
CCB  for  resol  utioa  based  on  majority  vote  of  the 
AIS  CCB. 

k.  Consist  of  uonvoting  members  which  are 
AIS  support  contractors,  a  Military  Service,  PSE, 
or  PLFA.  The  cochairpersons  will  decide  when 
uonvoting  members  shonld  attend  CCB  meetings. 

|.  Consist  of  the  following  AIS  CCB  cochair¬ 
persons  and  members  which  are  re  presen  tatives 
from  the  following  PSEs  and  PLFAs: 


CachairpertoM 
Lead  Technical  PSE  Votinf 

jMS  CCB  \*mtS  PSE  Mcmtxtf  Mcmbefl 

n^Mmud  DLA-Z,  C  DLA-A,  I,  DLA-L  DACO 

oTtin.  K.O.W  MAC.ru>A. 

ISaaagewcat 

muxrsMJ  DLA-Z,  O  DLA-P.Q,  DTOQDSAC, 

m£m  *c,w,  dla-l  DACO, 

Uiautotn!  I,  A  Depots,  DLSC, 

Supply  Ccaten 

TMhakil  and  DLA-Z,  S  DLA-t,  Q,  DIA-L,  DRMS, 

W,C,Of  DLSCDTIC, 

^  P  DSAC.DACO 

Dm*  Support  DLA-Z,  W  DLA-O,  C  DLA-L  D5AC, 

g,P  DLA-L  DACO 

Dfomatioc  DLA-Z  DLA-I.W,  DLA-L  DLA-C 

Systems  and  0  DAAS, 

TacfcsotoD  Centers,  DACO 

5.  The  AlS/Proqram  fPKfl  Working  Groups  will: 

a.  Serve  as  support  groups  to  the  AIS  CCB  with 
representative  members  from  the  Program  Manage¬ 
ment  Office,  the  appropriate  PSEs,  PLFAs,  project 
managerSi  and  contractors.  Some  AIS  Working 
Groups  may  only  require  coordination  between  PSE 
Coufigurtaion  Managers  and  the  AIS  Administrator 
in  lieu  of  a  formal  meeting  to  support  tbe  AIS  CCB. 

b.  Be  chaired  by  the  AIS  Administrator  of 
DSMO-O  and  will  support  the  Lead  Functional  PSE 
in  providing  recommendations  for  approval  or  dis¬ 
approval  of  proposed  changes  preaented  to  the  AIS 

CCB.  t  . 

c.  Consist  of  the  FM  Working  Group  which  is 
established  in  support  of  a  chartered  Program 
Manager  who  is  responsible  for  an  AIS  modern¬ 
ization  program.  Meetings  will  be  scheduled  by  the 
Program  Manager  or  the  designated  PM  Configura- 
tioa  Manager. 

A  Be  supported  by  the  PSE  and  PM  Configura¬ 
tion  Managers  and  the  AIS  Administrator.  They 
will  be  responsible  for  reviewing,  screening, 
monitoring,  reporting,  nnd  preparing  cases.  . 

e*  Serve  as  the  official  communications  link  be¬ 
tween  the  AIS  or  program  participants  to  document 
interface  agreements  and  change  procedures, 
resolve  interface  problems  between  allocated  Cls, 
and  coordinate  change  requests,  deviations,  and 
waivers. 

f.  Review  all  proposed  configuration  changes 
which  might  affect  the  established  baselines.  When 
interface  control  complexity  exists  because  of  tbe 
»any  components  involved,  the  working  group  will 
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be  expanded  to  consul  of  other  memberships  such 
ns  from  the  system  integration  responsible  agent, 
contractors  involved,  and  Government  agencies  par¬ 
ticipating  in  the  system  development. 

g  Reach  an  agreement  on  the  disposition  of 
proponed  changes  and  make  recommeadations  to 
the  AIS  CCB  or  approve/disapprove  as  delegated. 

6.  The  Confimration  Manaiert  will: 

a.  Be  located  at  the  PLFAs,  PSEs,  in  AIS  Mod¬ 
ernisation  Program  tad  Project  Offices,  at  contrac¬ 
tor  sites,  or  in  s  Military  Service. 

b.  Control  the  input  of  changes  into  the 
oitomated  CM  system,  distribute  changes  based  on 
classification  and  responsibilities,  and  perform 
other  functions  associated  with  change  requests  for 
a  designated  AIS  or  site. 

c.  Review  and  validate  the  functional  benefit  es¬ 
timates  on  incoming  change  requests. 

d.  Conduct  initial  review  of  AWRs,  ECPs,  and 
DAW*  to  determine  compliance  with  this  regula¬ 
tion. 

c.  Include  a  Configuration  Manager  of  DLA-Z 
which  will  be  the  Executive  Secretary  of  the  Cor¬ 
porate  CCB  and  Information  Systems  and  Technol¬ 
ogy  CCB.  The  Configuration  Manager  of  the 
Functional  PSE  who  cochairs  an  AIS  CCB  will  be 
designated  as  the  Executive  Secretary  of  the  AIS 
CCB.  The  Executive  Secretary  will  prepare  the 
agenda  for  the  meetings,  record  and  report  minutes, 
maintain  appropriate  configuration  status  records, 
prepare  the  CCB  directives,  execute  CCB  action 
Rems,  maintain  statu  of  outstanding  action  items, 
and  provide  recommendations  to  the  chairpersons 
on  CCB  decisions  and  issues. 

f.  Ensure  that  requests  for  changes  which  are 
directly  related  within  an  application  or  scheduled 
for  simultaneous  implementation  with  a  change  in 
another  SAIS  are  consolidated  as  one  AWR  and  as¬ 
signed  to  the  appropriate  functional  CPA  AIS  area 
for  management 

g.  Manage  and  interface  with  the  automated 
systems  used  for  configuration  management,  be 
primarily  responsible  for  data  costained  ia  the  dis¬ 
tributed  CM  system  for  an  AIS  or  program,  ensure 
that  chaage  request  data  is  Input  into  the  system, 
and  be  responsible  for  the  data  transferred  or 
entered  into  the  DLA  Corporate  CM  system. 

h.  Request,  vis  a  Program  Configuration 
Manager,  that  the  Program  Manager  assigns  a 
Project  Configuration  Manager(s)  if  the  volume, 


size,  or  location  of  the  program  dictates  a  dis¬ 
tributed  CM  structure  to  manage  and  control  effec¬ 
tively. 

7.  The  CM  Users  will; 

a.  Be  located  at  PZ-FA  sites,  at  approved  con¬ 
tractor  locations,  and  at  appropriate  Military  Ser¬ 
vices  and  will  have  read  and/or  write  access  to  a 
distributed  CM  system. 

b.  Consist  of  Functional  PSEs  who  will  utilize 
the  Corporate  CM  system  at  HQ  DLA  and  dis¬ 
tributed  CM  systems  located  at  CD  As. 

c.  Consist  of  PLPAs  who  soil  utilize  the  CM  sys- 
tem  to  input  change  requests  status  information  and 
to  maintain  and  control  site  configuration  data. 
Reports  to  reflect  changes  in  baseline  date  located 
la  the  Corporate  CM  system  will  be  produced  as  re¬ 
quested  by  the  CCBt. 

d.  Consist  of  contractors  who  wSl  utilize  com¬ 
patible  CM  software  which  will  allow  direct  trans¬ 
mission  of  reports  or  status  information  as 
requested  by  program  or  AZ5  offices.  Compatibility 
with  DLA's  CM  system  will  not  eliminate  the  need 
for  aeparate  CM  support  systems  for  internal 
management. 

e.  Consist  of  Military  Services  who  will  be  giver 
consideration  for  direct  access  to  the  DLA  CM  sys¬ 
tem  when  necessary  to  input  change  requests  for 
DoD  systems  or  interoperable  AIS  systems. 

VIII.  PROCEDURES.  The  following  procedures 
wilt  be  performed  within  DLA  for  configuration 

management. 

A.  Confirurs tioc  Management  Planning 

1.  The  following  planning  which  precedes  the  ac¬ 
tual  Of  process  will  establish  an  environment  for 
managing  system  changes.  After  the  AIS  Master 
Program  Plan  is  submitted  to  the  PSEs  and  PLFAs 
to  provide  guidaaee,  the  PLFAs  will  submit 
proposals  for  future  initiatives  to  the  appropriate 
fanctioaal  PSE  for  review  and  approval.  The  PSEs 
will  consolidate  responses  from  the  PLPAs  and  es¬ 
tablish  prioritized  initiatives  within  their  functional 
area.  PSE  initiatives  must  reflect  agency  priorities 
«j  described  ia  the  DLA  Strategic  Plan  prepared  by 
DLA-L  and  as  defined  in  the  Information  Resour¬ 
ces  Management  Plan  prepared  by  DLA-Z.  The  in¬ 
itiatives  list  will  be  submitted  to  DLA-Z  for  n 
funding  assessment  and  for  preparation  of  recom¬ 
mendations  for  the  budget  process.  The  approved 
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requirement!  will  be  incorporated  into  the  annuel 
AIS  Master  Program  Plan. 

Z  The  Lead  Function!  PSEs  will  consolidate  the 
AWR  requests  which  have  bees  approved  by  the 
AIS /PM  Working  Group  and  AtS/PM  CCB  and 
develop  their  FPL.  The  requests  on  the  FPL  should 
relate  to  prioritized  initiatives  is  the  AIS  Master 
Program  Plan.  Other  new  requirements  not  trace¬ 
able  to  the  initial  prioritized  initiatives  nod  man¬ 
dated  requirements  must  be  evaluated  and 
incorporated  into  the  next  PPL,  or  processed  as  an 
emergency  cue  and  incorporated  into  the  existing 
FPL.  A  methodology  for  prioritizing  AWRs  for  the 
FPL  is  provided  in  the  DLA  CM  Plan.  Priorities 
must  be  identified  for  functional  initiatives  and  for 
the  one  or  more  AWRs  which  may  be  processed 
against  an  approved  initiative. 

B.  Configuration  Identification.  Baseline*  shall 
be  employed  throughout  the  life  cycle  of  a  system  to 
ensure  an  orderly  transition  from  one  major  com¬ 
mitment  point  to  the  next  in  the  system  engineering, 
production,  and  logistic  support  processes.  These 
baselines  are  documented  by  approved  configura¬ 
tion  identification,  normally  prepared  in  accord¬ 
ance  with  DoD-STD*7935A,  which  is  the  basis  for 
control  of  changes  in  system/C!  requirements.  The 
requirements  should  be  traceable  to  the  top-level 
specification.  If  conflicts  arise  between  the 
baselines,  or  their  approved  configuration  iden¬ 
tification,  the  order  of  precedence  shall  be:  func¬ 
tional,  allocated,  and  product  unless  waived  by  the 
appropriate  decision  authority.  Configuration  item 
identification  numbering  and  marking  shall  be  in  ac¬ 
cordance  with  the  DLA  CM  Plan.  Software  ahould 
be  identified  by  an  unchanging  bast  number  and 
changing  version,  release,  and  npdate  numbers. 
Baseline  data  will  be  entered  by  PSE,  CDA,  PLFA, 
or  PM  Configuration  Managers,  as  appropriate,  to 
support  the  existing  Corporate  and  distributed 
A1S/PM  automated  CM  systems. 

1.  DLA-ZO  will  establish  current  operational 
baselines  of  AISs  or  modernization  programs  as  re* 
qnired  by  the  CM  Program.  The  operational 
baseline  will  be  maintained  in  antomsted  systems  or 
entered  into  the  automated  CM  system. 

Z  The  PSE/PM  Configuration  Managers  must 
ensure  that  tbc  configuration  items  to  be  controlled 
such  as  hardware,  software,  facilities,  teiecom- 
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munications,  and  documents  arc  identified  for  AISs 
or  programs. 

3.  The  PSE/PM  Configuration  Managers  or  a 
designee  must  enter  the  functional  baseline,  which 
includes  documentation  of  functional  requirements 
contained  in  the  conceptual  functional  require* 
meets  document  and  functional  description  and  the 
Government  Furnished  Equipment  (GFE)  which  in* 
eludes  hardware,  software,  facilities,  and  telecom¬ 
munications  as  stated  in  the  contract  or  agreement. 
The  functional  baseline  is  established  when  the  Sys¬ 
tem  Specification  is  approved  by  the  program  office, 
functional  PSE,  or  the  PLFA  aite. 

4.  The  PSE/PM  Configuration  Managers  or  a 
designee  must  enter  the  allocated  baseline  data  such 
ns  hardware,  software,  documents,  and  facility  in¬ 
formation.  The  allocated  baseline  will  comprise  the 
contractor's  or  developer's  proposal  of  bow  the 
functional  requirements  wilt  be  met.  The  allocated 
baseline  could  contain  some  or  all  of  the  GFE,  as 
contained  in  the  functional  baseline,  and  any  addi¬ 
tional  ADP/T.  The  allocated  baseline  is  established 
with  the  Preliminary  Design  Review  in  which  DLA* 
Z  and  the  functional  PSEs  attend. 

5.  The  PLFA  Configuration  Managers  ora  desig¬ 
nee  must  enter  data  from  the  detailed  design  docu¬ 
ments,  initisl  product  specifications,  and  DD  Forms 
250,  Material  Inspection  and  Receiving  Report,  to 
establish  the  product  baseline.  The  product 
baseline  usually  comprises  hardware,  software, 
telecommunications,  and  documentation  that  has 
been  received  by  the  developer  or  contractor, 

C.  Configuration  Control.  Configuration  control 
regulates  changes  to  the  system  and  CIs  after  formal 
establishment  of  each  and  any  of  their  baseliaes. 
Engineering  changes,  waivers,  or  deviations  affect¬ 
ing  the  Government's  interest  in  the  configuration 
of  a  Cl  shall  be  limited  to  those  which  are  necessary 
or  offer  significant  benefit  to  the  Government.  The 
types  of  changes  are  ones  that:  correct  deficiencies; 
effect  substantial  life  cycle  cost  savings;  make  a  sig¬ 
nificant  effectiveness  change  in  operational  or  logis¬ 
tics  support  requirements;  or  prevent  or  allow 
desired  slippage  in  an  approved  schedule.  Changes 
in  configuration  shall  be  classified  as  Class  I  or 
Class  I!  engineering  changes  in  accordance  with 
MIL-STD-433,  MIL-STD-4S0B,  and  the  criteria 
defined  in  this  regulation  for  classifying  a  ease.  The 
time  line  or  schedule  for  the  review/approval  con- 


70 


MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


DL./tM  • 


figuration  control  procedures  is  in  the  CM  plan.  If 
a  contract  has  already  been  awarded  with  estab¬ 
lished  timeframes  lor  ihe  review/approval  con¬ 
figuration  control  procedures  and  cannot  be  easily 
modified  to  reflect  the  standard  DLA  timeframes, 
the  supporting  CM  personnel  must  be  notified  of  the 
contractual  timeframes.  The  following  CM  proce¬ 
dures  as  reflected  in  figure  1  will  be  used  to  control 
change  request  documents  nad  problem  trouble 
reports. 

I.  System  Change  Reouest.  Deviation/Waiycr, 
Engineering;  Change  Propostl.  Specification 
phanae  Notice.  A  requestor  from  the  FSE,  PLFA, 
or  Military  Services  may  generate  an  AIS  or  mod¬ 
ernisation  program  requirement  which  shall  result 
in  the  preparation  of  as  SCR,  on  an  AWR  form,  by 
the  requestor.  Deviations  and  waivers  shall  be 
treated  as  basic  inadequacies  to  specification  re¬ 
quirements  and  should  be  granted  only  when  there 
is  en  overriding  benefit  to  the  Government,  and  an 
Insignificant  support  and  mission  impact  on  the  are* 
affected.  They  shall  be  prepared  by  contractors  and 
CD  As  and  approved  in  nccordance  with  the  CM 
Finn  and  MIL-STD-4S0B.  Deviations  and  waivers 
shall  be  classified  as  Class  I  or  Class  II  and 
prioritized  as  major,  minor,  or  critical.  ECPs  will 
only  be  prepared  by  contractors  in  nccordance  with 
MIL-STD-4S0B  The  Government  may  require  that 
the  contractor  submit  s  letter  prior  to  preparing  a 
Class  1  ECF,  ia  order  to  preelude  cost  to  the 
Government  for  as  unsolicited  ECP .  The  SCN  will 
be  used  by  a  contractor  to  propose,  transmit,  nnd 
record  a  change  to  a  specification  affected  by  an 
ECP,  or  to  update  a  specification  change  unrelated 
to  an  ECP  or  design  change. 

n.  A  FM  Class  Vll  SCR  is  forward ed  directly  to 
the  FM  Configuration  Manager.  The  AIS  CUss  I/II 
BCR  is  forwarded  to  the  Sponsoring  FSE  Configura¬ 
tion  Manager.  A  contractor  shall  also  submit  ECPs 
or  Deviation  and  Waivers  directly  to  the  Program  or 
Project  Configuration  Manager. 

b.  When  a  Configuration  Manager  ia  a  Program 
Office  or  project  receive*  a  PM  SCR,  ECP ,  or  DAW, 
the  request  and  status  information  is  entered  in  the 
automated  CM  system  and  the  change  request  is 
classified  according  to  enclosure  2.  If  approved  by 
the  Program  or  Project  Configuration  Manager,  a 
CUss  I!  SCR  or  DAW  is  forwarded  to  the  CDA  for 
possible  implementation  through  reserve  resources. 


A  contractor's  Class  II  ECP  or  DAW  is  approved  or 
disapproved  and  return  to  the  contractor. 

c.  A  CUss  I  PM  SCR,  Deviation/Waiver,  or 
ECP  is  forwarded  to  the  Sponsoring  PSE  Con¬ 
figuration  Manager  for  review.  The  Lead  FSE  can 
submit  a  PAR  form  to  the  CDA  in  order  to  aid  in 
evaluating  whether  to  accept  a  change  request 
from  a  user  tud  forward  the  change  to  DLA-Z  for 
processing.  If  disapproved,  the  change  is  returned 
to  the  requestor. 

d.  Approved  changes  ere  forwarded  to  DSMO- 
0  for  coordination  and  technical  analysis  of  the  cue 
by  DLA-Z  divisions  and  the  appropriate  CDA.  The 
analysis  performed  by  the  CD  As  must  be  docu¬ 
mented  on  the  AWR  form.  The  AWR  form  must  in¬ 
clude  a  technical  discussion  on  how  the  functional 
requirements  will  be  implemented.  The  analysis 
must  also  address  system  interfaces,  environmental 
changes  snch  as  facility  impact,  estimated  hardware 
end  software  requirements,  implementation  alterna¬ 
tives  with  pros  and  eons,  and  impact  statements. 
The  AWR  form  must  contain  cost  data  for  acquisi¬ 
tion  or  modifieatioa  of  a  technical  platform.  This 
gyt«  will  include  a  gross  estimate  of  ADP/telecom- 
muni cations  costs,  nnd  ADP  manpower  resources  to 
advise  PSEs  of  development  and  implementation 
resources  and  impact  oa  production  systems. 

c.  The  completed  Request  Impact  Analysis 
Report  on  the  case  is  provided  to  the  Sponsoring 
PSE  Configuration  Manager  to  add  benefits  and 
determine  if  the  ease  is  still  approved  for  process¬ 
ing  or  should  be  rejected  and  returned  to  the  re¬ 
questor.  AIS  CUss  D  SCRs  will  be  approved  by 
DSMO  after  proper  coordination  and  forwarded  to 
the  CDA  for  implementation  from  resources 
reserved  for  Class  II  SCRs.  AIS  CUss  H  ECP(SCN) 
or  DAW  will  be  forwarded  to  the  contractor  for  im¬ 
plementation. 

f.  If  the  functional  sponsors  have  approved  the 
SCR  or  ECP  and  adequately  identified  the  benefits, 
the  case  is  prepared  by  the  Lead  PSE,  PM  Con¬ 
figuration  Managers  nnd  the  AIS/PM  Administrator 
for  review  by  the  AIS  ox  PM  Working  Group.  The 
AIS  Working  Group  will  provide  recommendations 
for  approval  of  cases  to  the  AIS  CCB,  unless  the 
working  group  is  delegated  approval  authority. 

g.  The  AIS  CCB  will  approve  or  disapprove 
recommendations  from  the  AIS  or  PM  Working 
Group  (unless  decision  authority  is  delegated  to  a 
working  group)  on  CUss  1  SCRs,  ECPs,  SCNs, 
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Deviations,  aod  Waivers.  The  chairpersons  of  the 
A1S  CCB  should  make  the  decision  and  sign  the  DD 
Form  1694  for  critical  aod  major  deviations  and 
waivers  as  reqaeated  from  CDAs  and  contractors. 
The  contractor  must  obtain  consideration  from  the 
Government  for  each  approved  deviation  or  waiver. 
The  requestor  is  notified  if  the  CCB  disapproves  the 
change  request. 

h.  If  the  case  is  determined  to  be  n  global 
change  impacting  the  ngencies  mission  areas  in 
each  s  manner  that  the  Corporate  CCB  oust 
evaluate  the  impact,  the  case  must  be  prepared  by 
the  Corporate  Configuration  Manager  for  review 
and  approval  by  the  Corporate  CCB.  If  approved 
by  the  CCB,  the  SCR  change  will  be  incorporated  > 
in  the  CDA  Project  Development  Plan  (PDP)  or 
the  ECP  will  be  provided  to  a  contractor  for  im» 
piementation.  If  the  case  meets  the  criteria  of  a 
new  modernisation  program,  it  must  be  reviewed 
by  the  DLA  AIS  Review  Connell.  It  most  also  be 
elevated  to  the  Major  AIS  Review  Council  based 
on  established  criteria  and  dollar  thresholds  as 
euted  in  enclosure  2. 

2.  Technology  Work  Requests.  An  SCR  may  re* 
quire  the  preparation  of  a  Technology  Work  Re* 
quest  (TWR)  for  technology  changes  or  a  TWR  can 
be  a  technical  requirement  usually  generated  by 
DLA-Z  personnel. 

a.  The  TWR  section  on  the  AWR  form  should 
be  prepared  by  DI-A-Z1,  DSMO,  DLA*ZO  or  the 
CDA  and  contain  control  numbers  on  the  AWR  to 
maintain  status  from  receipt  of  the  request  through 
implementation.  An  AWR,  with  the  TWR  section 
filled  in  and  the  SCR  section  blank,  is  submitted  to 
the  CDA;  entered  by  the  CDA  ia  the  automated  CM 
system;  and  is  scheduled  through  the  PDP  process 
lor  implementation. 

b.  DLA-Z  initiated  TWRs  will  be  submitted  to 
DLA-ZI  for  review  and  then  forwarded  to  the  CDA 
for  processing.  If  the  CDA  has  processed  a  TWR 
aad  it  requires  further  DLA-Z  review,  it  is  for¬ 
warded  to  DLA-ZI  for  review  and  guidance  by  the 
Information  Systems  and  Technology  CCB  prior  to 
incorporating  the  request  in  the  CDA  PDP  for  im¬ 
plementation. 

3.  Problem  Tronble  Reports.  The  requestor  will 
submit  by  telephone  a  Problem  Trouble  Report 
(FTR)  to  the  responsible  CDA  who  wilt  document 
problems  relating  to  hardware,  software,  or 
telecommunications.  The  actnal  problem  will  be 


documented  with  status  updates  on  the  AWR  Form 
or  the  automated  CM  system  io  the  PTR  section. 
Software  problems  will  be  defined  ns  warm  line  or 
hot  line  in  accordance  with  the  urgency  and  priority 
of  the  response.  Immediate  resolution  is  required 
of  a  hot  line  which  is  a  critical  problem  that  prevents 
the  accomplishment  of  a  SAIS  task  necessary  for 
operations  and  for  which  no  reasonable  alternative 
action  can  be  taken.  Valid  hot  lines  take 
precedence  over  all  other  CDA  development  efforts 
aod  are  aormally  corrected  within  24  bo^rs  from 
receipt  of  sufficient  data.  A  warm  line  is  a  noncriti- 
eal  program  conformance  problem  that  either  does 
not  affect  any  necessary  SAIS  tasks,  or  if  affected, 
those  tasks  can  be  temporarily  accomplished 
through  alternate  action  until  CDA  resources  can  be 
provided  to  resolve  the  problem.  The  Configuration 
Manager  at  the  CDA  will  return  the  AWR  with  the 
FTR  information  to  the  requestor  if  an  SCR  is  re¬ 
quired  and  explain  the  reason  for  changing  the  type 
of  request.  DLA-Z  will  assist  the  CDA  in  resolving 
cases  where  the  validity  or  classification  of  a  PTR  is 
in  qncstion  and  cannot  be  resolved  by  the  requestor 
and  CDA. 

a.  PTRs  are  submitted  to  the  CDA  when  SAIS 
programs  are  aot  in  conformance  with  design 
specifications  and  are  causing  mission  degradation 
because  of  their  design.  PTRs  are  also  submitted 
when  SAIS  programs  do  not  perform  according  to 
the  approved  design  details  as  reflected  in  either  the 
initially  approved  Functional  Description  (FD)  or  a 
subsequently  approved  system  change  request;  the 
program  failed  to  execute  as  anticipated;  or  the 
documentation  is  seriously  deficient. 

b.  Hot  lines  may  be  submitted  by  telephone  or 
electronically  to  the  CDA  on  the  PTR  form  during 
doty  or  nonduty  hours.  Hot  lines  of  a  very  sensitive 
nature  should  be  forwarded  ia  a  secure  manner  as 
sensitive  material  to  the  CDA,  such  as  explaining  a 
system  problem  in  which  oae  can  eater  the  operat¬ 
ing  system.  Hot  line  PTRs  initially  submitted  by 
telephone  mnst  be  entered  iato  the  automated  CM 
system  by  the  CDA  nrithin  24  hours.  Complete 
status  oa  PTRs  will  be  maintained  ia  the  autoauted 
CM  system  by  the  CDA  and  will  be  available  for  read 
access  by  DLA*Z,  PSEs,  and  other  PLFAs.  PTR 
status  reports  wit!  be  available  from  the  automated 
CM  system  for  the  originator,  PLFAs,  PSEs,  and 
AIS  Administrators  to  acknowledge  receipt  of  the 
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PTR  and  provide  inform  stio*  of  action  taken  or 
planned. 

t.  The  CDA  will  schedule  and  process  FTRs 
wkkia  the  man-hour  percentage  allocated  for  FTRs 
by  the  appropriate  A1S  FD P. 

D.  Configuration  States  Accounting.  The  cob- 
figuration  status  aecovatiag  function  provides 
traceability  of  the  current  approved  configuration 
identification  and  of  the  changes  thereto,  and  acts 
M  i  management  too)  for  monitoring  all  related 
tasks  resulting  from  sack  changes.  Configuration 
Status  Accounting  will  be  invoked  on  contracts 
•sing  the  applicable  sections  of  MIL- STD -483.  The 
data  elements  used  in  Configuration  Status  Ac¬ 
counting  are  contained  in  the  DLA  CM  Automated 
System  (CM AS)  Requirements  and  Implementation 
Flan. 

X.  A  representative  from  the  program  office  or 
AXS  Administrator  or  Site  Administrator  shall  con¬ 
duct  inproccu  reviews  (IP**)  on  system  configura¬ 
tion  documentation,  as  required,  with  the  functional 
FSE,  contracting,  and  the  developer/contractor  at¬ 
tending. 

2.  DSMO  will  prepare  an  Information  Resource 
Management  (IRM)  prereview  in  accordance  with 
the  General  Services  Administration  FIRMR  20119 
whieb  states  that  a  configuration  management 
report  on  the  Major  Information  Systems  is  re¬ 
quired. 

3.  The  CM  users  and  Configuration  Managers 
mast  report  to  the  appropriate  personnel  within  the 
CM  organization  to  fulfill  statu  accounting  via  the 
automated  CM  system. 

E.  Configuration  Reviews  and  Audits.  Configura¬ 
tion  reviews  and  audits  verify  that  the  specifications 
and  related  documentation  comply  with  regulations 
and  policy.  The  audit  function  validates  the 
achievement  of  development  requirements  and  the 
accuracy  of  a  production  configuration  documented 
In  the  Cl’s  technical  documentation.  The  criteria 
for  reviews  nad  audits  are  outlined  in  MIL-STD- 
1521 B  and  the  CM  Flan.  The  technical  reviews  shall 
be  conducted  by  the  CDA  or  the  Program  Office, 
representing  DLA-Z,  as  appropriate. 

1.  The  functional  FSEs  shall  conduct  the  Systems 
Requirements  Review  which  is  a  forma!  review  of 
the  functional  baseline.  DLA-Z  will  participate  in 
the  review. 


2.  DLA-Z  shall  conduct  a  Systems  Design 
Review  with  the  developer  to  ensure  the  design  sup¬ 
ports  the  requirements.  The  risk  of  the  allocated  re¬ 
quirements  and  the  design  will  be  reviewed  with  the 
functional  FSEs. 

3.  DLA-Z  shall  conduct  a  Preliminary  Design 
Review  (FDR)  which  is  s  technical  review  of  the 
design.  The  FDR  will  be  presented  by  the  developer 
to  DLA-Z  for  review  with  the  functional  FSEs. 

4.  DLA-Z  shall  conduct  the  Critical  Design 
Review  at  the  end  of  the  Definition/Design  Phase  to 
ensure  that  the  detailed  design  satisfies  the  require¬ 
ments.  It  will  be  presented  by  the  developer  with 
the  functional  FSEs  attending. 

{.  DLA-Z  shall  conduct  s  Final  Design  Review, 
with  the  functional  FSEs  attending,  to  certify  the 
final  system  design  and  to  ensure  acquisition  plans 
will  provide  the  resources  needed  to  fully  support 
the  system  design  and  approved  schedule. 

6.  DLA-Z  shall  conduct  a  Test  Readiness 
Review,  with  the  functional  PSEs  participating, 
which  examines  the  System  Integration  Testing 
results  nad  final  system  functionality.  The  results 
are  certified  in  the  system  test  by  the  CDA. 

7.  A  team  of  DLA  representatives  or  interna!  in¬ 
spectors  shall  perform  the  Functional  Configuration 
Audit  which  determines  whether  the  performance, 
speeified  in  the  system  specifications,  has  been 
achieved  and  will  result  in  the  certification  of  the 
functional  test  by  the  Lead  Fuactiomal  PSE. 

t.  A  team  of  DLA  representatives  or  internal  in¬ 
spectors  shall  perform  the  Product  Configuration 
Audit.  This  andit  physically  examines  all  configura¬ 
tion  items,  including  software  and  hardware,  and 
earn  pare*  them  against  their  respective  technical 
documentation.  The  results  of  this  audit  will  be  the 
verification  of  the  Product  Baseline  by  the  audit 
team  and  the  certification  of  the  environmental  test 
by  the  Head  of  the  PLFA. 

9,  DLA-Z  shall  conduct  •  Formal  Qualification 
Review  with  the  functional  PSEs  participating.  This 
review  is  a  formal  examlnatloa  of  the  Operational 
Test  and  Evaluation  (OTJtE)  and  follow-on  OTJtE 
test  results  to  determine  that  all  operations  meet 
specifications.  The  result  of  the  review  will  be  cer¬ 
tification  of  the  Initial  Operational  Capability  by  the 
Head  of  the  PLFA. 

XO.  It  is  the  responsibility  of  the  host  of  the 
reviews  to  ensure  that  the  proper  personnel  are  in¬ 
vited  to  attend  the  reviews.  FSE  Configuration 
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Managers,  Prog  ram  Configuration  Managers,  and 
Corporate  Configuration  Managers  should  be  given 
the  tavitalioa  to  attend. 

11.  The  Configuration  Managers,  functional 
PSEs,  Program  Offices,  and  PLFA  sites  shall 
respond  to  CM  requests  tad  audits  from  the  Cor* 
porate  CCB. 

IX.  FORMS  AND  REPORTS 

A.  FORMS.  The  following  is  a  list  of  the  required 
Suras  utilized  in  the  CM  process.  A  description  of 
how  to  complete  all  the  forms  outlined  below  is  in 
the  DLA  CM  Plan.  The  regulatioa  or  military  stand¬ 
ard  is  also  provided  as  appropriate. 

1.  OLA  Form  558,  558-1/2/3,  Automated  Data  ' 
Processing/Telecommunication*  Work  Request 
<DLA(AR)2510(Z)). 

2.  DD  Form  1692,  Engineering  Change  Proposal, 
page  1  as  described  in  M1L-STD-480B. 

3.  DD  Form  1692-1,  Engineering  Change 
Proposal,  page  2  as  described  in  MIL-STD-480B. 

4.  DD  Form  1692-2,  Engineering  Change 
Proposal,  page  3  as  described  ia  MIL-STD-480B. 

5.  DD  Form  1692-3,  Engineering  Change 
Proposal,  page  4  as  described  in  MIL-STD-480B. 

6.  DD  Form  1693-4,  Engineering  Change 
Proposal,  page  5  ns  described  ie  M1L-STD-480B. 


BY  ORDER  OF  THE  DIRECTOR 


2  End  j 
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7.  DD  Form  1693-5,  Engineering  Chtnge 
Proposal,  page  6  as  described  in  MIL-STD-480B. 

8.  DD  Form  1696,  Specification  Change  Notice, 
as  described  in  MIL-STD-480B. 

9.  DD  Form  1694,  Request  For  Devia¬ 
tion/Waiver,  as  described  in  MIL-STD-480B. 

10.  DLA  Form  1799,  Pre-analysis  Requirement. 

11.  Other,  letter,  military  letter,  or  memoran¬ 
dum. 

B.  REPORTS.  The  following  are  reports  utilized 
ia  the  CM  process.  The  Users  Manual  for  the  DLA 
automated  CM  system. 

t  STANDARD  REPORTS.  The  following  is  a 
list  of  the  standard  types  of  reports  generated  from 
the  DLA  automated  CM  system. 

a.  Configuration  Items  Summary  Report 

b.  Requirements  Traceability  Reports 

c.  Configuration  Item  Review  and  Audit  Status 
Report 

d.  Documentation  Reports 

e.  Configuration  Reporting 

t  Change  Control  Reports 

g.  Change  Implementation  Reports 

h.  Problem  Trouble  Reporting 

i  Data  Dictionary  Reports 

2.  AD  HOC  REPORTS.  AD  HOC  queries  will 
be  available  for  the  CM  users  and  will  provide  for 
various  sorting  capabilities. 


VARY  C.  TUCKER 
Colonel,  USA 

Staff  Director,  Administration 
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LIST  OF  DEFINITIONS 


pyfinitioni  used  For  the  purpose  of  this  regulation, 
t he  following  definitions  apply. 

1.  APP/T  Work  Request  (AWRL  A  document 
mtd  to  record  and  transmit  interna!  DLA  require¬ 
ments  (SCR,  TWR,  and  FTR),  npprovnlddisap- 
prevail,  and  related  iaplementaiioa  actioni. 

2.  Allocation.  A  specific  distribution  of  funds. 

J,  Automated  Information  System  (AISV  A  coliec* 
tbs  of  functional  user  and  ADP  personnel,  procedures 
md  equipment,  including  ADP/Teleconunumcations 
equipment  nnd  software,  which  is  designed,  built, 
operated,  and  maintained  to  collect,  record,  process, 
•lore,  retrieve,  transmit,  and  display  information. 

4.  Automated  Information  System  Administrator. 
The  individual  designated  by  the  Assistant  Director, 
Office  of  Information  Systems  and  Technology, 
DLA-Z,  to  be  responsible  and  accountable  for,  nnd 
perform  general  oversight  of  an  A1S. 

5.  Automated  Information  System  New  Develop* 
pent.  A  development  effort  whose  size  and  scope 
requires  Life  Cycle  Management  as  defined  in 
DLAR  4730.1,  DoDD  7920.1  and  DoD- STD-7935 A. 

g.  Baseline.  A  configuration  identification  docu¬ 
ment  or  a  set  of  such  documents  formally  designated 
by  the  Government  nt  a  specific  time  during  a  Cl’s 
life  cycle.  Baselines,  plus  approved  changes  from 
those  baselines,  constitute  the  current  approved  con¬ 
figuration  identification.  For  configuration  manage¬ 
ment  purposes  there  are  three  baselines,  which  are 
established  sequentially,  as  follows; 

a.  Functional  Baseline  (TBLl  The  sakinUy  ap¬ 
proved  documentation  describing  a  system’s  or 
item's  functional  characteristics  and  the  verification 
required  to  demonstrate  the  achievement  of  those 
specified  functional  characteristics. 

b.  Allocated  Baseline  (ABL1.  The  initially  ap¬ 


proved  documentation  describing  an  item's  function¬ 
al  and  interface  characteristics  that  ate  allocated 
from  those  of  a  higher  level  Cl,  iaterfaee  require¬ 
ments  with  interfacing  configuration  items,  addition¬ 
al  design  constrnints  nnd  the  verification  required  to 
demonstrate  the  achievement  of  those  specified 
functional  and  interface  characteristics. 

c.  Froduct  Baseline  fPBLV  The  initially  ap¬ 
proved  documentation  describing  ill  of  the  aeces- 


wry  functional  tod  physical  cJuracteristies  of  the  Cl, 
■ay  required  joint  and  combined  operation,  inter¬ 
operability  characteristic!  oft  Cl  (including  a  com- 
preheetive  nummary  of  the  other  aerviee(j)  nnd 
allied  interfacing  Cla  or  systems  and  equipments), 
and  the  (elected  functional  tad  physical  characterise 
tics  designated  for  production  acceptance  testing 
aad  tests  necessary  for  support  of  the  Cl. 

7.  Benefits.  Outputs  or  effectiveness  expected  to 
be  received  or  achieved  over  time  as  a  result  of  un¬ 
dertaking  a  proposed  investment. 

8.  Case.  A  case  consists  of  the  appropriate  SCR, 
ECP/SCN,  TWR,  or  D&W  forms  with  the  classifica¬ 
tion  worksheet  nnd  the  justification  nnd  supporting 
documentation  attached. 

9.  Central  Design  Activity  fCDAV  A  DLA  activity 
that  has  been  assigned  Standard  AIS  development 
•ad  maintenance  responsibilities  by  DLA-Z. 

10.  Computer  Software  for  Software").  A  combina¬ 
tion  of  associated  computer  instructions  and  com¬ 
puter  data  definitions  required  to  enable 
computer  hardware  to  perform  computation! 
control  functions. 

11.  Computer  Software  Configuration  Item 
(CSCn.  A  configuration  item  for  computer 
software. 

12.  Computer  Software  Documentation.  Techni¬ 
cal  data  or  information,  including  computer  listings 
nnd  printouts,  which  documents  the  requirements, 
design  or  details  of  computer  software;  explains  the 
capabilities  and  limitations  of  the  software;  or 
provides  operating  instructions  for  using  or  support¬ 
ing  computer  software  during  the  software’s  opera¬ 
tional  life. 

13.  Configuration.  The  functional  and  physical 
characteristics  of  hardware,  firmware,  software  or  a 
combiaatioa  thereof  as  set  forth  in  technical 
documentation  and  achieved  in  a  product 

14.  Configuration  Audit.  The  verification  of  a  Cl’s 
conformance  to  specifications,  drawings  nnd  other 
contract  requirements. 

4*  Functional  Configuration  Audit  (FCAV  The 
formal  examination  of  functional  characteristics  of  • 
Cl,  prior  to  acceptance,  to  verify  that  the  item 
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Achieved  (he  performance  specified  in  its  functional 
or  allocated  configuration  identification. 

b.  Product  (Physical)  Coafiguratioa  Audit 
fPCAV  The  formal  examination  of  the  *as  built*  cob* 
figuration  of  a  Cl  against  its  techaical  documents- 
tioa  to  ettablisb  the  Cl's  initial  product 
configuration  ideatificatioa  (PCI). 

15.  Configuration  Control  The  systematic 
proposal,  justification,  evaluation,  coordination,  ap¬ 
proval  or  disapproval  of  proposed  changes,  and  the 
implementation  of  all  approved  changes  in  the  con¬ 
figuration  of  a  Cl  after  formal  establishment  of  its 
baseline. 

16.  Configuration  Control  Board  (CCB).  Aboard 
composed  of  technical  and  administrative  repre¬ 
sentatives  who  approve  or  disapprove  proposed  en¬ 
gineering  changes  to  an  approved  baseline. 

17.  Configuration  Identification.  The  selection  of 
the  documents  to  comprise  the  baseline  for  the  sys¬ 
tems  and  Clt  involved,  and  the  numbers  and  other 
identifiers  affixed  to  the  items  and  documents.  The 
approved  documents  that  identify  and  define  the 
item's  functional  and  physical  characteristics  in  the 
form  of  specification,  drawings,  associated  lists,  io- 
terface  control  documents,  and  documents 
referenced  therein.  The  configuration  identification 
is  developed  and  maintained  through  three  distinct 
evolutionary  increasing  levels  of  detail,  each  used  for 
establishing  a  specific  baseline.  The  two  levels  of 
configuration  identification  are  as  follows: 

a.  Configuration  Item  (CIV  Aa  aggregation  of 
hardware,  firmware,  aofeware,  or  aay  of  it*  discrete 
portions,  which  satisfies  an  end  nse  function  and  is 
designated  for  configuration  management.  CIs  may 
vary  widely  in  complexity,  size  and  type,  from  aa 
aircraft,  ship  or  electronic  system  to  s  test  meter  or 
ronnd  of  ammunition.  During  development  and 
manufacture  of  the  initial  (prototype)  production 
configuration,  CIs  are  those  items  whose  perfor¬ 
mance  parameters  and  physical  characteristics  must 
be  separately  defined  (specified)  and  controlled  to 
provide  management  insight  needed  to  achieve  the 
overall  end  use  function  and  performance.  Any  item 
required  for  logistic  support  and  designated  for 
separate  procurement  is  a  Cl. 

b.  Configuration  Management  (CMI  A  dis¬ 
cipline  applying  teehnieal  and  admiaistrative  direc¬ 
tion  and  surveillance  to: 


(J)  Identify  and  document  the  functional  and 
physical  characteristics  of  CIs; 

(2)  Audit  the  CIs  to  verify  couformanee  to 
specifications,  interface  control  documents  and 
other  contract  requirements; 

(3)  Control  changes  to  CIs  and  their  related 
documeataiioc;  and 

(4)  Record  and  report  information  needed  to 
manage  CIs  effectively,  including  the  status  of 
proposed  changes  and  the  implementation  status  of 
approved  changes. 

18.  Configuration  Status  Accounting  (CSAj.  The 
recording  and  reporting  of  information  needed  to 
manage  configuration  effectively,  including: 

a.  A  listing  of  the  approved  configuration  iden¬ 
tification; 

b.  The  status  of  proposed  changes,  deviations, 
and  waivers  to  the  configuration; 

c.  The  implementation  status  of  approved  eban- 
ges;  and 

d.  The  configuration  of  all  units  of  the  Cl  in  the 
operational  inventory. 

29.  Contractor.  An  individual,  partnership,  com¬ 
pany,  corporation,  association  or  other  service 
having  a  contract  with  the  procuring  activity  for  the 
design,  development,  manufacture,  maintenance, 
modification  or  supply  of  items  under  the  terms  of  a 
contract.  A  Government  activity  performing  any  or 
all  of  the  above  functions  is  considered  to  be  a  con¬ 
tractor  for  configuration  control  purposes. 

20.  pata.  Recorded  information,  regardless  of 
form  or  characteristics,  including  administrative, 
managerial,  financial,  scientific,  technical,  engineer¬ 
ing,  antf  logistics  data,  whether  required  to  be 
delivered  to  the  Government  or  retained  by  the  eon- 
tractor,  as  well  as  data  developed  by  the  Govern¬ 
ment. 

21*  Deficiencies.  Deficiencies  consist  of  two  types: 

a.  Conditions  or  characteristics  la  any  hardware 
or  software  which  are  mot  in  compliance  with  the 
specified  configuration  identification;  or 

b.  Inadequate  (or  erroneous)  configuration  iden¬ 
tification  which  has  resulted,  or  may  result,  in  CIs 
that  do  not  fulfill  approved  operational  require¬ 
ments. 

22.  Detailed  Functional  Requirement.  A  act  of 
detailed  instructions  developed  in  AWR  Form  558 
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using  the  general  functional  requirement  to  provide 
both  functional  and  data  processing  personnel  with 
clear  concise  atateaaeBU  of  the  specific  functional 
logic  and  functional  operation  capabilities  to  be 
designed,  programmed,  tested,  amd  implemented. 

23.  Deviation,  A  specific  writtea  authorization, 
granted  prior  to  the  manufacture  of  aa  item,  to 
depart  from  a  particular  performance  or  design  re¬ 
quirement  of  a  specification,  drawing  or  other  docu¬ 
ment  for  n  specific  period  of  time.  A  deviation 
differs  from  an  engineering  change  in  that  an  ap¬ 
proved  engineering  change  requires  corresponding 
revision  of  the  documentation  defining  the  affected 
item,  whereas  a  deviation  does  not  contemplate 
revision  of  the  applicable  specification  or  drawing.  ' 

24.  Engineering  Change  An  alteration  in  the  ap¬ 
proved  configuration  identification  of  a  Cl  voder 
development,  delivered  or  to  be  delivered. 

a.  Class  T  engineering  change  (See  enclosure  2.) 

b.  Class  II  engineering  change.  (See  enclosure 

2.) 

25.  Engineering  Change  Priorities.  The  priority 
assigned  to  a  Class  1  engineering  change,  which 
determines  the  methods  and  resources  to  be  used  in 
review,  approval  nod  implementation.  The  priority 
will  determine  the  relative  speed  at  which  the  ECP 
it  to  be  reviewed,  evaluated,  ordered  and  imple¬ 
mented,  if  approved.  Priorities  can  be  emergency, 
argent,  routine,  or  minor. 

26.  Engineering  Change  Proposal  (BCP).  A 
proposed  engineering  change  and  the  documenta¬ 
tion  by  which  the  change  is  described,  justified,  and 
submitted  by  the  contractor  to  the  procuring  activity 
for  approval  or  disapproval. 

27.  flCP  Types.  A  term  covering  the  subdivision  of 
ECPs  on  the  basis  of  the  completeness  of  the  avail¬ 
able  information  delineating  and  defining  the  en¬ 
gineering  change.  They  will  be  identified  at 
preliminary  or  formal. 

26.  Firmware.  The  combination  of  a  hardware 
device  and  computer  instructions  or  computer  data 
that  reside  as  read  only  software  on  the  hardware 
device.  The  software  eaaaot  be  readily  modified 
under  program  eontrrl. 


29.  Fit.  The  ability  of  an  item  to  physically  inter 
face  or  interconnect  with  or  become  an  integral  par 
of  another  item.  (Uaed  in  MIL-STD-480B) 

30.  Form,  The  defined  configuration  of  an  item  in 
eluding  the  geometrically  measured  configuration 
density,  mnd  weight  or  other  visual  parameters  whicl 
uniquely  characterize  m  item,  component  or  as 
atmbly.  For  software,  form  denotes  the  language 
language  level  and  media.  (Used  in  M1L-STD-480B/ 

31.  Function.  The  action  or  actions  which  an  itetr 
Is  designed  to  perform.  (Used  in  MIL-STD-4S0B) 

32.  Genera?  Functional  Requirement.  A  set  of 
functional  goals,  objectives,  criteria,  policies,  and/or 
other  considerations  documented  in  a  AWR  which 
describe  in  non-ADP  terminology,  and  without 
regard  to  ADP  equipment  or  its  considerations,  new 
or  revised  tasks  to  be  accomplished  by  an  established 
Standard  Automated  Information  System. 

23.  Hardware.  Articles  made  of  material,  such  as 
tools,  fittings,  machine  parts,  weapons,  vehicles,  but 
not  including  computer  programs  or  technical 
documentation. 

3**  Interface  Control.  The  process  of: 

a.  Identifying  all  functional  and  physical  charac¬ 
teristics  relevant  to  the  interfacing  of  two  or  more 
items  provided  by  one  or  more  organizations. 

b.  Ensuring  that  proposed  changes  to  these 
characteristics  are  evaluated  tad  approved  prior  to 
implementation. 

35.  Item.  A  nonspecific  term  used  to  denote  any 
product,  including  systems,  subsystems,  assemblies, 
subassemblies,  units,  sets,  accessories,  computer 
programs,  computer  software  or  parts. 

36.  Lead  Functional  FSE.  The  HO  DLA  FSE 
designated  by  the  Director,  DLA,  as  having  overall 
responsibility  for  developing  end  coordinating  func¬ 
tional  priorities  within  AIS(s). 

37.  Life  Cycle  Cost.  The  sum  total  of  the  direct,  in¬ 
direct,  nonrecurring,  recurring,  and  other  related 
costs  incurred,  or  estimated  to  be  incurred,  ia  the 
design,  development,  prodaetion  (including 
manufacture  and  fabrication),  acquisition,  test  and 
evaluation,  acceptance,  operation,  maintenance, 
modernization,  deactivation  nod  support  of  a  con¬ 
figuration  item  over  its  anticipated  life  span. 
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38.  Modernization  Changes  to  an  existing  AIS 
that  involve  implementing  state  of  the  art  automation 
concepts  or  technolog ies. 

S9.  Non-Dcvclopmental  Item  fNDI).  Non- 
devclopmental  items  are  existing  developed  and 
available  hardware  or  software  that  are  capable  of 
fal filling  DoP  requirements,  thereby  minimizing  or 
eliminating  the  need  for  costly,  Government-spon- 
aored  research  and  development  (RAD)  programs. 
An  KDI  is  osnally  an  off-the-shelf  or  commercial- 
type  product,  but  may  also  include  hardware  or 
aoftware  already  developed  by  or  for  the  DoD,  or 
other  Military  Services  or  foreign  military  forces. 

40.  Physical  Characteristics.  Quantitative  and 
qualitative  expressions  of  materiel  features,  such  as 
composition,  dimensions,  finishes,  form,  fit,  and 
their  respective  tolerances. 

41.  PreAnilvtis  Requirement  (PARI  Form  util¬ 
ized  by  the  Lead  PSE  which  obtains  technical  infor¬ 
mation  from  the  CD  A  on  the  proposed  requirement 
in  order  to  aid  in  the  decision  of  whether  or  not  to 
proceed  on  with  the  processing  of  the  requirement 
by  forwarding  it  to  DLA-Z. 

42.  Privately  Developed  Item  (PDI).  An  item 
developed  at  private  expense  and  offered  to  the 
Government,  with  Government  control  of  the 
article's  configuration  normally  limited  to  its  form, 
fit  and  function. 

43.  Problem  Tronble  Report.  A  report  that  iden¬ 
tifies  a  program  that  is  not  in  conformance  with 
design  specifications  as  approved  in  the  original  FD 
or  subsequent  SCR,  or  that  is  causiag  mission 
degradation  because  of  its  design.  Depending  upon 
their  criticality,  FTRs  are  transmitted  to  the  design 
activity  as  either  hot  lines  or  warm  lines. 

44.  Project.  A  planned  AIS  new  development  or 
modification  initiative  having  elearly  defined  scope 
and  specific  objectives.  A  project  may  be  imple¬ 
mented  as  a  single  entity  or  ns  sequential  increments. 

45.  Protect  Development  Plan  fPPPV  A  document 
designed  to  provide  corporate  viaibility  for  all  SA1S 
development  nnd  serves  as  a  contract  between  HQ 
D LA  and  the  various  DLA  central  design  activities. 
(See  DLAR  4730.6  for  details.) 

46  Specification.  A  document  intended  primarily 
for  use  in  procurement,  which  describes  the  essential 


technical  requirements  for  items,  materiels  or  ser¬ 
vices  including  the  procedures  for  determining 
whether  or  not  the  requirements  hnvt  been  met. 

47.  Specification  Chance  Notice.  A  document 
used  to  propose,  transmit  and  record  changes  to  a 
specification. 

48.  Sponsoring  Principal  Staff  Element.  The  HQ 
DLA  PSE  having  functional  responsibility  for  a  sys¬ 
tems  change  request. 

49.  Standard  Automated  Information  System.  A 
uniform,  nnd  centrally  designed  AIS  consisting  of 
computer  programs  which  support  computer  ap¬ 
plications  at  DLA  mission  and  support  activities. 
SAtSs  are  developed  and  maintained  by  CD  As  in  ac¬ 
cordance  with  standard  DLA  policies  and  proce¬ 
dures. 

50.  System.  A  composite  of  equipment,  skills,  and 
techniques  capable  of  performing  or  supporting  an 
operational  role,  or  both.  A  complete  system  in¬ 
cludes  all  equipment,  related  facilities,  material, 
software,  services  and  personnel  required  for  its 
operation  and  support  to  the  degree  that  it  can  be 
considered  a  self-sufficient  item  in  its  intended 
operational  environment. 

51.  System  Change  Request  fSCR).  A  requirement 
to  change  an  existing  system  and  transmitted  on  an 
ADP/T  Work  Request  form. 

52.  Technical  Data.  Recorded  information, 
regardless  of  form  or  characteristics,  of  a  technical 
mature.  Technical  data  may  document  research,  ex¬ 
perimental,  developmental,  or  engineering  work  or 
be  used  to  define  a  design  or  process  or  to  procure, 
produce,  support,  maintain,  or  operate  materiel.  The 
data  may  be  graphic  or  pictorial  delineations  in 
media  such  as  drawings  or  photographs,  text  in 
specifications  or  related  performance  or  design  type 
documents,  or  computer  printouts.  Examples  of 
technical  data  include  research  and  engineeriag 
data,  engineering  drawings  nnd  associated  lists, 
specifications,  standards,  process  sheets,  manuals, 
technical  reports,  catalog  item  identifications  nnd 
related  information,  nnd  computer  aoftware 
documentation.  Technical  data  does  not  include 
computer  software  or  financial,  administrative,  cost 
and  pricing,  and  management  data,  or  other  informa¬ 
tion  incidental  to  contract  administration. 
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53.  Technical  Reviews  A  eerie*  of  system  en- 
gtneeriag  activities  by  which  the  technical  progress 
#a  •  project  is  aucucd  relative  to  its  technical  or 
contractual  requirement*.  The  review*  are  cod* 
dueled  at  logical  transition  points  it  the  develop* 
Meat  effort  to  identify  and  correct  problems 
resulting  from  the  work  completed  thus  far  before 
the  problems  can  disrupt  or  delay  the  technical 
popes*.  The  reviews  provide  a  method  for  the  con¬ 
tractor  and  procuring  activity  to  determine  that  the 
development  of  a  Cl  and  its  identification  have  met 
contract  requirements.  (See  MIL-STD-1521.) 
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54.  Technology  Work  Request.  Technology  Work 
Requests  are  requirements  prepared  on  the  AWR 
form  to  request  changes  to  the  DLA  technical  plat¬ 
form  through  resources  from  the  CDA  technology 
organizations. 

55.  Waiver.  A  written  authorization  to  accept  an 
kern  which,  daring  manufacture  or  having  been  sub* 
Bitted  for  inspection,  is  found  to  depart  from 
specified  requirements,  but  is  considered  suitable 
for  use  flas  is*  or  after  repair  by  an  approved  method. 


S 
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CRITERIA  UTILIZED  BY  CONFIGURATION 
MANAGERS  TO  CLASSIFY  A  CASE 


I.  GENERAL  There  art  various  types  of  request!  at 
shows  is  paragraph  II  below  that  eta  be  submitted  as 
a  case  aad  wit  hie  each  type  is  a  set  of  farther  classifies- 
lions  which  seed  to  be  decided  upon  to  defuse  the 
priorities,  characteristics,  and  categories  of  the  re¬ 
quest.  The  decisioB  process  for  classification  of  a  re¬ 
quest  is  shown  in  exhibit  X.  The  FIRST  decision  that 
needs  to  be  made  i ti  What  it  the  type  of  request? 

II.  TYPES  OF  REQUESTS.  There  are  five  types  of 
requests  which  are  classified  as  Class  I  or  Class  II  and 
are  submitted  on  standard  forms  identified  below:  , 

ADP/T  Work  Request  (SCR,  TWR,  L  PTR)  -  DLA 
Form  556  Series. 

Request  for  Waiver  -  DD  Form  1694. 

Request  for  Deviation  •  DD  Fora  1694. 

Engineering  Change  Proposal  -  DD  Form  1692 
Series. 

Specificatioa  Change  Notice  -  DD  Form  1696. 

The  SECOND  decision  that  needs  to  be  made  is: 
What  class,  within  the  type  already  selected,  is  the 
request? 

A.  CLASS  I  CRITERIA  If  one  of  the  following 
criteria  is  fulfilled,  the  request  is  a  Class  I  classifica¬ 
tion  or  major  request: 

1.  A  change  to  a  Cl  (i.eM  software,  hardware). 

2.  Performance  impacted  by  change. 

3.  Reliability,  main  taxability  or  survivability  im¬ 
pacted  by  change. 

4.  Interface  characteristics  impacted  by  change. 

5.  Functional/technical  requirements  impacted 
by  change. 

6.  Government  Furnished  Equipment  (GFE)  im¬ 
pacted  by  change. 

7.  Security  impacted  by  change. 

8.  Compatibility  or  interoperability  impacted  by 
change. 

9.  Operation  aad  maintenance  manuals  impacted 
for  which  adequate  chaage/revisioa  funding  is  not 
provided  in  exalting  contracts. 

10.  Schedule  is  impacted  by  chaage. 

11.  Funding  is  impaeted  by  change. 


12.  Interchangeability,  substitutability,  oi 
replaeeability  (as  applied  to  CIs)  impacted  b} 

change. 

13.  The  following  contractual  factors  are  im 
parted: 

a.  Cost  including  fees  and  incentives. 

b.  Contractual  deliveries. 

c.  Contract  warranties  or  guarantee. 

d.  Scheduled  contract  milestones. 

14.  Change  corrects  deficiencies. 

15.  Effectiveness  change  in  operational  or  logis 
tics  support  requirements. 

16.  Change  produces  a  substantial  life  cycle  cosi 
cavings. 

17.  Change  prevents  slippage  X  an  approved 
Class  I  AWR  (SCR)  delivery  schedule.  A  Class  1 
AWR  must  use  the  FDF  process  as  the  method  of  im¬ 
plementation. 

B.  CLASS  II  CRITERIA.  If  only  the  following 
criteria  is  fulfilled,  the  request  is  a  Class  II  minor  re¬ 
quest: 

1.  MXor  change  to  a  Cl  or  its  documentation  with 
its  impact  being  within  the  scope  of  a  current  con¬ 
tract  without  changing  the  Government  approved 
configuration  identification  other  than  to  add  the 
Class  II  change  to  the  Product  Cl. 

2.  Corrects  documentation  errors;  adds  clarifying 
notes  or  views;  adds,  deletes  or  corrects  nonex¬ 
ecutable  comment  Unes  of  code  to  software. 

3.  Enhances  contractor  productivity  without 
detriment  to  the  Government. 

4.  Interchangeability,  substitutability  or 
replaeeability  of  CIs  are  not  nffected. 

After  DLA-Z  approval,  Class  II  AWRs  will  be  im- 
plemeated  from  CDA  Reserve  Resources  which  will 
be  established  during  the  FDF  process. 

The  Specification  Change  Notice  (SCN)  can  be  sub¬ 
mitted  by  itself,  but  usually  accompanies  an  En¬ 
gineering  Change  Proposal  A  proposed  SCN  is 
used  to  update  a  specification  cither  to  support  a 
proposed  ECF  or  a  design  change  or  because  the 
specification  needs  to  be  modified.  An  SCN  is  only 
classified  as  a  Cass  !  or  If  change;  there  is  not  a 
lower  classification  description. 
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The  THIRD  decision  Chat  needs  to  be  made  is: 
What  priority,  within  the  type  already  selected,  is 
the  request? 

til.  ADP/T  WORK  REQUEST.  After  the  ADP/T 
Work  Request  (AWR)  is  determined  to  be  either 
Our  i  or  Cu“  11,  the  following  dassificatiou  shall 
he  made  by  the  PSE  or  PM  Configuration  Manager  in 
order  to  define  the  case.  Defining  the  case  will 
fad  Li  talc  the  analysis  and  evaluation  of  the  case  for 
technical  review,  and  actions  to  be  taken  by  the  work* 
k|  group,  AIS  CCB,  and  Corporate  CCB  as  needed. 
The  technical  review  by  DLA*Z  and  the  CDA  of  an 
emergency  or  mandated  request  with  a  short  suspense 
shall  lake  no  more  than  48  hours.  All  other  categories 
of  requests  shall  be  completed  within  30  calendar  days ' 
of  receipt  of  the  request  by  DLA-Z.  An  AWR  is  util- 
feed  only  for  DLA  internal  requests.  The  AWR  con¬ 
tains  three  possible  types  of  requests  which  are  system 
change  requests  (SCRs),  technology  work  requests 
fTWRs),  and  Problem  Trouble  Reports  (PTRs),  pre¬ 
viously  known  as  a  Program  Trouble  Report.  The  fol¬ 
lowing  are  the  priority  choices  relating  to  nn  SCR: 

A.  Mandated  -  A  requirement  mandated  by  law, 
regulatory  agencies,  the  Director  of  DLA,  OSD 
direction,  or  intcrservicc  agreement  (i.e.,  DLA  . 
policy  letters,  Approved  MILSTRIF  Change  Letters 
(AMCLs),  DIDS  change  requests),  usually  includes 

a  suspense  date. 

B.  Mission  Essential  -  A  requirement,  which  if  not 
fulfilled,  will  stop  a  mission  or  support  area  from 
performing  its  function. 

C.  Routine  -  A  requirement  that  could  better  the 
performance  oft  mission  or  support  ares  or  does  not 
meet  the  criteria  of  a  mandated  or  missioa  essential 
priority  (*A*  or  *B’)» 

SCR  Characteristics.  After  one  of  the  priorities  are 
chosen,  as  mandated,  mission  essential,  or  routine, 
the  SCR  characteristics  must  be  further  defined. 
These  characteristics  are  one  of  the  following: 

1.  High  Payback  *  A  characteristic  of  *A*  or  *B- 
or  *C"  priority  choice  which  is  expected  to  produce 
tangible  savings  exceeding  810,000,  and  expected  to 
have  s  discounted  payback  period  of  2  years  or  leu. 

X  Technical  -  A  characteristic  or  “A*  or  "B*  Or  "C* 
priority  choice  which  is  designed  to  improve  the 
operating  efficiency  of  an  AlS  without  changing  its 
functionality. 


3.  Functional  -  A  characteristic  of  *A*  or  *B*  or 
•C*  priority  choice  which  is  designed  to  improve  the 
operating  efficiency  of  an  AIS  by  changing  its 
functionality. 

4.  Documentation  •  A  characteristic  of  *A*  or  *B* 
or  *C*  priority  choice  which  affects  documentation 
only,  ien  no  program  changes  required. 

SCR  Categories.  Within  each  of  the  above  stated 
priorities,  a  category  must  be  further  defined.  The 
following  are  the  categories  of  an  SCR  request: 

a.  New  Development  -  This  requirement  will  ul¬ 
timately  the  form  of  a  Mission  Need  Statement 
(MNS),  but  might  be  initiated  as  an  SCR  on  the  AWR 
form. 

b.  Modification  •  This  requirement,  which  in¬ 
cludes  the  adaptive  modifications,  must  be  sub¬ 
mitted  as  an  SCR  oa  an  AWR. 

PTR  Priorities.  The  following  are  the  priority 
choices,  as  depicted  in  exhibit  1,  relating  to  a  PTR: 

A.  Hot  Line  -  If  the  PTR  is  categorized  as  a  "hot 
line9,  it  will  be  solved  immediately. 

B.  Warm  Line  *  If  the  PTR  is  categorized  as  a 
"warm  line",  it  will  be  solved  in  a  routine  manner 
using  CDA  reserved  resources  established  during 
the  PDP  process. 

A  PTR  could,  after  review,  be  diagnosed  as  a 
modification  and  not  a  maintenance  requirement, 
depending  on  the  findings  from  the  troubleshooting 
of  the  problem,  resulting  in  the  preparation  of  an 
SCR  by  the  receiving  CDA. 

TWR  Priorities.  The  following  are  the  priority 
choices,  as  depicted  in  exhibit  1,  relating  to  a  TWR: 

A.  Critical  •  If  not  done,  it  will  seriously  impair  ef¬ 
ficiency  or  function  of  mission  accomplishment. 

B.  Inviolate  Due  Date  -  The  due  date  cannot  be  vio¬ 
lated. 

C.  Expedite  Mission  Operation  -  The  result  would 
improve  function  or  efficiency. 

D.  Other  -  Those  that  are  not  defined  above  would 
be  prioritized  as  other. 

TWR  Characteristics.  After  one  of  the  priorities 
are  chosen,  as  critical,  inviolate  due  date,  expedite 
mission  operation,  or  other,  the  TWR  ebaraeteris- 
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tics  Must  be  further  defined.  These  characteristics  C.  Minor 

•re  one  of  the  following.  .  Waiver  consists  of  ncceptacce  of  a  lot  of  items 

1  Public  Low  or  DoD  Regulation  -  If  (he  require*  having  a  number  of  minor  defects  in  the  sample 
mem  is  mandatory  because  of  public  law,  directive,  etc.  equalling  or  exceeding  the  number  that  requires 

2.  DLA  Director  or  DoD  Sponsored  -  If  the  re*  rejection  of  the  lot. 

•virement  has  beta  requested  by  the  DLA  Director 


•r  DoD. 

3.  PSE  Sponsored  *  If  the  requirement  is  apon- 
aored  by  a  PSE. 

4.  Other  •  Those  that  are  not  defined  above  would 
he  characterized  as  other. 

TWR  Categories.  Within  each  of  the  above  stated 
priorities,  a  category  mast  be  farther  defined.  The 
following  are  the  categories  of  a  TWR  request: 

a.  Initial  Submission  •  When  the  request  is  sub* 
mined  for  the  first  time. 

b.  Resubmission  *  When  the  request  has  been 
submitted  on  a  previous  occasion. 

c.  Cancellation  -  When  the  request  Is  being  can* 
celled. 

IV.  REQUEST  FOR  WAIVER.  The  following  are 
the  priorities  of  a  waiver 

A.  Critical 

•  Waiver  consists  of  acceptance  of  an  item  having  a 
critical  defect. 

or 

-  Nonconformance  with  contract  or  configuration 
Identification  requirements  involving  security  or 
safety. 

B.  Major 

-  Waiver  consists  of  acceptance  of  a  lot  of  items 
having  a  number  of  major  defects  in  the  sample 
equalling  or  exceeding  the  number  that  requires 
rejection  of  the  lot. 


•  Consists  of  acceptance  of  an  Item  having  a  major 
defect. 

or 

*  Nonconformance  with  contract  or  configuration  idea* 
tification  requirements  involving  performance; 
reliability,  iaterchangeabilty;  survivability  or  main¬ 
tainability  of  the  hem  or  its  repair  parts;  effective  use  or 
operation,  specifications  such  as  weight  or  appearance. 


-  Consists  of  acceptance  of  an  item  having  a  minor 
defect 

or 

*  Having  a  nonconformance  with  contract  or  configura¬ 
tion  identification  requirements  which  does  not  involve 
any  of  the  factors  listed  under  *A‘  or  *B#  criteria. 

Critical  and  major  priority  (*A*  and  *B#)  -  can  only 
be  classified  as  a  Class  I  request;  should  be  ap- 
proved/disapproved  within  30  calendar  days  of 
receipt  by  procuring  activity;  and  must  be  approved 
by  a  DLA  contracting  officer. 

Minor  priority  (*C*)  •  Is  classified  as  a  Class  II  re¬ 
qnest;  and  should  be  approved/disapproved  within 
10  working  days  of  receipt  by  the  approval  activity. 

V.  REQUEST  FOR  DEVIATION.  The  following  are 
the  priorities  of  a  deviation: 

A.  Critical 

•  Deviation  is  a  departure  from  a  characteristic  in 
the  documentation. 

or 

» A  departure  involving  security  or  safety. 

B.  Major 

Deviation  is  a  departure  involving  performance; 
reliability,  interchangeability,  survivability,  main¬ 
tainability. 

or 

Durability  of  the  item;  effective  use  or  operation; 
specifications,  ix .  weight,  size,  or  appearance. 

C  Minor  -  Deviation  Is  a  departure  which  does  not 
Involve  above  *A*  and  *B’  factors. 

Critical  and  major  priority  (*A*  nod  "B*)  can  only 
be  classified  as  a  Class  I  request;  should  be  ap¬ 
proved/disapproved  within  30  calendar  days  of 
receipt  by  procuring  activity,  and  must  be  approved 
by  DLA  contracting  officer. 


85 


MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


..ad  2 

DLAR  4730  3 


Minor  Priority  (*C*)  •  is  classified  as  a  Class  II  re* 
quest;  and  should  be  approved/diiapproved  within 
10  working  days  of  receipt  by  the  approval  activity. 

VI.  ENGINEERING CHANGE  PROPOSALS.  The 
following  are  l be  priorities  of  an  ECP: 

A.  Emergency 

•  A  change  in  operational  characteristics  which  if 
not  accomplished  without  delay  may  seriously  com* 
promise  national  security. 

or 

►To  correct  a  hazardous  condition  which  may  result 
la  serious  injury  to  personnel  or  in  extensive 
damage/destruction  of  equipment  which  usually  will' 
require  withdrawing  the  item  from  service  tem¬ 
porarily  or  diseonti suing  further  testing  or  develop¬ 
ment  pending  resolution  of  the  condition. 

B.  Urgent 

•  A  change  which  if  not  accomplished  expeditiously 
may  seriously  compromise  the  mission  effectiveness 
of  deployed  system. 

or 

•  To  correct  s  potentially  hazardous  condition  which 
if  uucorrected  could  result  in  injury  to  personnel  or 
damage  to  equipment,  but  allows  continued  use  of 
the  affected  item  provided  the  operator  has  been  in¬ 
formed  of  the  hazard  and  appropriate  precautions 
have  been  defined  and  distributed  to  the  user. 

or 

•  To  meet  significant  contractual  requirements  (i.e., 
when  lead  time  will  necessitate  slipping  approved 
production,  or  deployment  schedules  if  the  change 
was  not  incorporated. 

or 

•  To  affect  an  interface  change  which  If  delayed 
would  cause  a  schedule  slippage  or  increase  cost. 

or 

•To  affect  net  life  cycle  cost  savings  to  the  Government 
through  value  engineering,  or  through  other  cost  reduc¬ 
tion  efforts  where  expedited  processing  of  the  change 
will  be  a  mqjor  factor  in  realizing  lower  costs. 

C.  Routine  -  A  change  in  which  emergency  or  ur¬ 
gent  is  not  applicable. 


D.  Minor 

•  A  change  that  does  not  affect  interchangeability, 
substitutability  or  replace  ability  of  CIs,  or  when 
repairable,  their  subassemblies  and  parts. 

or 

•  A  substitution  of  parts  or  material  which  does  not 
have  a  functional,  logistic  or  reliability  impact. 

or 

•  A  change  in  documentation  only  (errors,  notes,  or 
comments). 

Emergency,  urgent,  or  routine  ("A*  and  *BP  and  *C*)  - 
can  only  be  defined  as  a  Class  I  request;  requests  with 
either  *A#  or  priority  have  a  higher  priority  than 
routine.  The  processing  time  for  an  emergency  re¬ 
quest  for  decision  and  contractual  authorization  shall 
take  no  more  than  43  hours;  the  processing  time  for  an 
urgent  request  shall  take  no  more  than  30  calendar 
days;  and  the  processing  time  for  s  routine  request 
shall  take  no  more  than  90  calendar  days. 

For  a  Class  1  ECP,  on  the  form  there  is  a  justifica¬ 
tion  code  which  explains  why  the  change  is  being  re¬ 
quested;  refer  to  DLA  CM  Plan,  under  Class  I 
engineering  change  proposal  section,  for  the  defini¬ 
tions  of  the  codes.  This  information  will  aid  ia  the 
classification  process.  For  example,  an  ECP  with  a 
justification  code  of  "V*  will  be  considered  to  be  a 
V  class  request;  while  a  *C*  class  ECP  with  a  code 
"R*  justification  will  have  a  higher  priority  than  the 
other  *C*  class  ECPs. 

Priority  *D*  •  can  only  be  classified  as  a  Class  II  re¬ 
quest  The  review  process  for  a  minor  request  will 
be  completed  within  3  workdays  after  receipt  by  the 
Government.  The  contractor  shall  not  implement 
the  change  until  U  is  approved  by  the  Government. 

For  all  priorities,  when  the  Government  disapproves 
ai  ECP,  the  originator  will  be  notified  in  writing 
within  30  calendar  days  of  the  decision  and  will  be 
given  the  reason  for  disapproval. 

The  THIRD  decision  Is  made  after  the  classification 
has  been  defined,  the  Configuration  Manager  of  the 
CDA  must  determine  if  the  request  has  global  (cor¬ 
porate)  impact  and  needs  to  be  reviewed  by  the  Cor¬ 
porate  CCB.  If  only  one  of  the  following  criteria  is 
fulfilled,  the  request  must  be  reviewed  by  the  Cor¬ 
porate  CCB. 
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VII.  CRITERIA  FOR  CORPORATE  RE* 
QUEST.  Whea  one  of  the  type*  of  request*  meet  the 
following  criteria,  is  depicted  is  exhibit  lt  it  will  be 
reviewed  and  approved  by  the  Corporate  OCB: 

1,  Coat  of  the  request  is  $1 5  million  ii  1  year  or  $75 
million  during  the  program/project, 

2,  Request  impacts  AISs  of  more  thao  oae  Lead 
Functional  PSE  responsibility  or  establishes  a  new 
A!S. 

3.  Configuration  item  (Cl)  purchase  which  is  global 
fin  nature  for  OLA. 

4.  Special  interest. 

Requests  that  fulfill  either  1  or  4  criterion  above 
should  be  classified  as  a  DAISRC/MAISRC  (mod¬ 


ernization)  program  and  the  requests  should  be 
referred  to  DSMO-R  to  begin  the  program  review 
process. 

The  AIS  or  PM  CM  Manager,  as  appropriate,  must 
review  and  validate  the  Working  Groups’  previously 
calculated  classifications  of  the  submitted  requests 
before  forwarding  to  the  A1S/FM  CCB. 

The  Corporate  CM  Manager  (DLA-Z*s  CM 
Manager)  and  support  staff  administratively  sup¬ 
port  the  Corporate  CCB.  The  Corporate  CM 
Manager  FIRST  must  review  and  verify  the  clas¬ 
sifications  previously  calculated  by  the  AIS/PM 
CCB.  Also,  the  Corporate  CM  Manager  classifies  if 
U  is  a  DAISRC/MAISRC  ease  as  defined  in  exhibit 
1. 


AN  EXAMPLE  OF  CLASSIFYING  AN  ECP 


First,  a  Configuration  Manager  most  decide  on  the 
class  of  the  ECP.  As  a  scenario  example,  the 
Program  Configuration  Manager  defines  the  clas¬ 
sification  of  an  ECP  as  a  Class  I  request. 

Next,  the  Program  Configuration  Manager  decides 
on  the  priority  of  the  ECP.  The  ECP  has  been 
defined  as  a  priority  C  (Routine)  ECP  by  meeting 
the  definition.  (Remember,  a  priority  C  ECP  lias 
automatically  a  Classification  of  a  Class  1  because  it 
is  considered  to  be  a  major  request.) 

Next,  the  CDA  Configuration  Manager  decides  if 
the  request  has  global  impact.  The  CDA  Configura¬ 
tion  Manager  decides  that  the  request  includes  a  Cl 


purchase  which  is  global  In  nature  for  DLA.  The 
CDA  Configuration  Manager  defines  the  request  as 
meeting  .the  criterion  defined  for  number  3  of  a 
global  request. 

The  Corporate  Configuration  Manager  decides  if 
the  request  ean  be  classified  as  a  DAISRC/MAISRC 
case.  (Remember,  a  number  3  Corporate  request  is 
not  qualifying  as  a  DAISRC/MAISRC  criterion.) 
The  Corporate  Configuration  Manager  defines  the 
case  as  not  being  a  DAISRC/MAISRC  case. 

Therefore.,  the  classification  of  the  request  by  the 
Configuration  Manager  is  as  follows  in  code  format: 
ECP-I.C3. 


MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  ( cont '  <3 ) 


FORMAT  7  pf  0  PATE  OF  POSITION;  0  M*r  92 

TYPE  OF  REPORT:  AUDIT 

PURPOSE  OF  INPUT;  INITIAL  POSITION 

AUDIT  TITLE  AND  NO.;  REVIEW  OF  SOFTWARE  DEVELOPMENT  AT  CENTRAL 

DESIGN  ACTIVITIES,  (Project  No.  IFE-0018) 

RECOMMENDATION  4b:  We  recommend  that  the  Commandant  of  tha  Marina  Corp;  tha 
Army  Diractor  of  Information  Syatama  for  Command,  Control,  Communications 
and  Computers;  tba  Navy  Commanding  Officer,  Naval  Information  Syatama 
Management  Canter;  tha  Air  Force  Deputy  Chief  of  Staff  Command,  Control, 
Conunicationa  and  Computara;  and  the  Director,  Def enae  Logiatica  Agency 
verify  recorded  labor  boura ,  and  uae  them  in  making  future  project 
estimates . 

DLA  COMMENTS:  Concur.  The  CDAs  utilise  a  n««  reaourca  management  tool 
which  contains  data  on  labor  hours  and  work.  The  supervisors  are 
responsible  for  the  accuracy  of  the  data.  The  data  captured  will  be 
utilised  in  aiding  the  CDAs  in  their  future  estimation  to  include  trend 
ana) ysis . 

[DISPOSITION: 

(  )  Action  is  ongoing.  Estimated  Completion  Date: 

(X)  Action  is  considered  complete. 

RECOMMENDATION  MONETARY  BENEFITS:  (WHERE  APPLICABLE) 

DLA  COMMENTS: 

ESTIMATED  REALIZATION  DATE: 

AMOUNT  REALIZED: 

DATE  REALIZED; 

INTERNAL  MANAGEMENT  CONTROL  WEAKNESS: 

I  )  Nonconcur.  (Rationale  must  be  documented  and  maintained  with 
your  copy  of  the  response.) 

(X)  Concur;  however,  weakness  is  not  considered  arterial.  (Rationale 
must  be  documented  and  maintained  with  your  copy  of  the  response.) 

{  )  Concur:  weakness  is  material  and  will  be  reported  in  the  DLA 
Annual  Statement  of  Assurance. 

ACTION  OFFICER;  Donna  McCloud,  DLA-ZSS ,  *44326,  2B  Jan  92 

PSE  REVIEW/ APPROVAL :  Bobby  L.  Parsons,  DLA-ZD,  Deputy  Executive  Director, 

Office  of  Information  Systems  and  Technology,  x46257, 
31  Jan  92 

DLA  APPROVAL:  Helen  T.  McCoy,  Deputy  Comptroller 
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MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


rOBMAT  Ml  »*«  0T  WSITIOB:  9  IUp  92 

TTPI  or  WOW;  AUDIT 

purpose  or  input;  initial  position 

AUDIT  TITLE  A ED  NO.  :  S£VIt«  OF  SOFTWARE  DEVELOPMENT  AT  CENTRAL 

PIS Z OF  ACTIVITIES.  (Project  No.  IFE-0018) 


BECOIMCSDATX ON  ft:  We  recomsmnd  that  the  Commandant  ©f  the  Marino  Corps;  the 
Aray .  Director  of  Information  Systams  for  Command ,  Control.  Co»»inication* 
and  Computers;  the  Navy  Commanding  Offieor.  Naval  Information  Systams 
Management  Cantor;  and  tha  Diractor,  Dafanaa  Logistics  Agency  davalop 
proeoduras  to  reevaluate  approved  software  ebangas.  similar  to  tha  Air 
Fores,  whan  aoftwara  davalopmant  costs  will  exceed  tba  latest  estimate  by  15 
percent . 


DLA  COMMENTS :  Concur.  In  addition,  DLA  re-evaluates  a  requirement  if  six 
months  has  passed  before  tha  requirement  has  begun  to  be  fulfilled.  This 
coincides  with  PLA's  established  project  resourcing  cycle. 


DISPOSITION: 

<  )  Action  is  ongoing ,  Estimated  Completion  Date: 

{ X )  Action  is  considered  complete. 

RECOftttENDATION  MONETARY  BENEFITS:  (WHERE  APPLICABLE) 

DLA  COMMENTS: 

ESTIMATED  REALIZATION  DATE: 

AMOUNT  REALIZED: 

DATE  REALIZED: 

INTERNAL  MANAGEMENT  CONTROL  WEAKNESS: 

(  )  No  nconcur .  (Rationale  must  be  documented  and  maintained  with 

your  copy  of  the  response.) 

(X)  Concur;  however,  weakness  is  not  considered  material.  (Rationale 
must  be  documented  and  maintainad  with  your  copy  of  the  response.) 

(  )  Concur;  weakness  is  material  and  will  ba  reported  in  the  DLA 
Annual  Statamant  of  Assurance. 

ACTION  OFFICER:  Donna  McCloud,  DLA-ZSS,  X44320,  28  Jan  92 

PSE  REVIEW/ APPROVAL:  Nobby  L.  Paraons ,  DLA-ZD .  Deputy  Executive  Director. 

Office  of  Inforsmtion  Systems  and  Technology.  x46257, 
31  Jan  92 


DLA  APPROVAL:  Bolen  T.  McCoy,  Deputy  Comptroller 


MANAGEMENT  COMMENTS:  DEFENSE  LOGISTICS  AGENCY  (cont'd) 


rouur  •  pt  • 


©ATS  OF  FOSITIOK:  •  M»r  02 


tm  OF  1SF0ST;  ATOIT 


PURPOSE  or  INPUT:  INITIAL  POSITION 

RUU1T  TITLE  AMD  NO.  :  REVIEW  OF  SOFTWARE  DEVELOPMENT  AT  CENTRAL 

SKSIGK  ACTIVITIES.  (Project  Wo.  IFE-0018) 


RECOMMENDATION  4c;  ••  ftcowtnd  that  the  Commandant  of  Corps; 

the  Army  Director  of  Information  Systems  for  Command .  Control, 

Communications  and  Computers;  tbs  Navy  Commanding  Officer,  N*val  Information 
Systsms  Mana|smsnt  Contor;  tbs  Air  Forco  Psputy  Chiof  of  Staff  Co*“nd» 
Control.  Communications  and  Computsrs;  and  tbs  Dirsetor,  Dsfsnss  Logistics 
Agency  require  that  ovartims  bo  ussd  to  most  only  tbosa  milostonss  that  ars 
cos  t -sf f set 1 vs . 


DLA  COMMENTS:  Concur.  DLA  uses  overtime  when  it  is  doomed  cost  effective. 
However .  cost  effectiveness  is  not  the  only  acceptable  criteria  for  using 
overtime.  Overtime  is  also  Justified  to  fulfill  e  mandated  or  an  emergency 
requirement.  For  trend  analysis  end  lessons- learned .  DLA  will  be  tracking 
the  actual  versus  estimated  use  of  resources . 


DISPOSITION: 

l  )  Action  is  ongoing.  Estimated  Completion  Date: 

(X)  Action  is  considered  complete. 

RECOMMENDATION  MONETARY  BENEFITS:  (WHERE  APPLICABLE) 

DLA  COMMENTS: 

ESTIMATED  REALIZATION  DATE: 

AMOUNT  REALIZED: 

DATE  REALIZED: 

INTERNAL  MANAGEMENT  CONTROL  WEAKNESS: 

(  )  Nonconcur.  (Rationale  must  be  documented  and  maintained  with 
your  copy  of  the  response.) 

(X)  Coneur:  however,  weakness  is  not  considered  material.  (Rationale 
must  be  documented  and  maintained  with  your  copy  of  the  response.) 

(  )  Concur;  weakness  is  material  and  will  be  reported  in  the  DLA 
Annual  Statement  of  Aasurance. 

ACTION  OFFICER:  Donna  McCloud.  DLA*ZSS,  *44325 .  SB  Jan  02 

PSE  REVIEW/ APPROVAL:  Bobby  L.  Parsons ,  DLA-ZD ,  Deputy  Executive  Director. 

Office  of  Information  Systems  and  Technology,  *43257, 
31  Jen  02 


DLA  APPROVAL:  Helen  T.  McCoy,  Deputy  Comptroller 


LIST  OF  AUDIT  TEAM  MEMBERS 


Nancy  L.  Hendricks,  Director  for  Financial  Management 

Terry  L.  McKinney,  Program  Director 

Carl  F.  Zielke,  Project  Manager 

Robert  P.  Bertocchi,  Team  Leader 

Gary  D.  Dressel,  Team  Leader 

Jerri  D.  Johnson,  Team  Leader 

Robert  M.  Anastasi,  Auditor 

Nancy  C.  Cipolla,  Editor 
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